- db-wg - mailman.ripe.net

[funEstuff] SELF RUN BUSINESS
by success＠highpro.com 04 Jun '98

04 Jun '98

============================================= We value your Free Subscription to funEstuff! THIS MONTH'S DRAWING: FREE FAX MACHINE!! ============================================= ---- There is a merger in the works involving Polygraph Records, Warner Brothers, and Keebler. It will be called Poly-Warner-Cracker. ---- The boy's clothing shop was giving away balloons to customers. One little fellow asked if he might have two. "Sorry," the clerk said, "but we give only one balloon to a child. Do you have a brother at home ?" The youngster was always truthful, but he wanted another balloon badly. "No," he replied regretfully, "but my sister does, and I'd like one for him." ---- SELF-RUN, ON-LINE BUSINESS FREE WEBPAGE, FREE MARKETING TOOLS "HOTTEST" INTERNET BUSINESS TODAY NO SIGN-UP FEES, NO QUOTAS TO MEET CHECK MY WEBSITE AT http://members.xoom.com/mat1014/ ============================================= Your Free Subscription is always appreciated. You may cancel your membership, at any time, by sending email to: success(a)highpro.com with the word REMOVE in the subject line. If you have any questions about this list, contact us at 409/788-5867 or visit us online at: http://www.tssolutions.com/ =============================================

1 0

[funEstuff] Subscription Confirmation
by success＠highpro.com 03 Jun '98

03 Jun '98

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ We appreciate your Subscription to funEstuff! _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Your Email has been entered into our system as a subscriber to "funEstuff". This email is being sent out in an attempt to confirm your Free subscription. We do not condone or tolerate "spam" in any shape or form. If your email has been entered in by someone other than yourself, or you wish to discontinue your subscription, REPLY to this email with the word REMOVE in the subject line. We will make sure that you do not begin receiving the regular funEstuff updates, announcements, and surveys. To remain subscribed to this Free list, simply ignore this email. Your subscription will begin within a few days. You may modify your marketing and information preferences at any time, by visiting our online registration form: http://www.tssolutions.com/funestuf.htm _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Total Success Solutions, Inc believes in and supports the responsible use of bulk email advertising to targeted and subscribed audiences, only. For more information, call us at 409/788-5867, or visit us at http://www.tssolutions.com/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0

down time on rpslii.ripe.net
by Joao Luis Silva Damas 28 May '98

28 May '98

Dear all, Tomorrow at 13:15 the phase II rpsl server at the RIPE NCC (rpslii.ripe.net) will be down for an estimated time of 1h 30m for physical relocation of the machine to a different location. Regards, Joao

1 0

(no subject)
by Gerald Winters 22 May '98

22 May '98

Hello All, Does someone from Ripe know the story on the "withdrawn" attribute for route objects? The value in the v2 ripe shows date plus email address whereas v1 had date only. 1. What is the rationale for the change? Thanks, --jerry ------- Forwarded Message Date: Tue, 19 May 1998 10:02:57 +0930 From: Mark Prior <mrp(a)connect.com.au> To: cengiz(a)isi.edu cc: Gerald Winters <gerald(a)merit.edu>, rps(a)isi.edu, merit-ie(a)merit.edu, cengiz(a)cat.isi.edu Subject: Re: RPSL phase ii software announcement Mark Prior on Tue, 19 May 1998 08:57:31 +0930 said: > Onto something completely different, I notice that the withdrawn > attribute under RIPE DB v1 was only a date, then RIPE DB v2 made it a > date and email address and finally RPSL has changed it back to just a > date again. What's the rationale for the changes? I'm just curious as > I have to deal with all three formats now :-( [snip...] It would be interesting to know why RIPE changed it from someone at RIPE who knows, assuming someone does :-) Mark. ------- End of Forwarded Message

3 2

The Absolute Easiest Program in Network Marketing to Earn Your New Car !!!
by success＠highpro.com 22 May '98

22 May '98

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ We appreciate your Subscription to funEstuff! If you would like to cancel your membership, simply REPLY to this Email with the word "REMOVE" in the SUBJECT Line. Our Automated System will delete your address immediately! If you prefer to have your remove request handled by a human, feel free to forward this entire email to us at "remove(a)tssolutions.com". We appreciate your patronage. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ "YOU CAN Drive a Brand New Car Every Two years for FREE..." Are you one of the millions of people in Network Marketing still searching for a Dependable Company that will provide an Opportunity that delivers what it says....? We have an Affordable Business Plan that offers : * Absolutely NO HYPE... * A No Sales Marketing Strategy that Anyone Can Do... * And a Very Lucrative Income for those that are willing to take the steps necessary to Change Their Life... Take your First Step and Click Here ==> <A HREF="http://www.northamericancoupon.com/flyers/fbruno.htm">Find Out Now!!!</A> Our Business Plan Provides you with the following Benefits: 1. Potential Income of $60K + Per Month.... 2. A Very Low One time Cost of $59.00... 3. $75.00 Fast Start Bonus Commissions Paid Weekly... 4. $$ Hundreds $$ in Savings on Items that you already buy... 5. A No Sales Marketing Strategy that Anyone can do... 6. Drive the New Car of Your Choice Every 2 Years for FREE... 7. Real legitimate Spillover into a 3 x 8 matrix ... 8. Training, Support, Marketing tools, Qualified Leads and Much More.... How many People can you think of that would like to drive a Brand New Car Every Two Years for FREE... and get paid while driving it...? Obviously right now, It's Up to you ... Get started early! Don't wait months down the road after you've been let down by several more deals... because you know what...We are going to Suprise the heck out of every one that takes this Business Plan as serious as We do !!! "You owe it to Yourself to Check us Out !!! "Have you called the Toll Free Number Yet...? Call 888-324-6252 (24 hrs.) -------- Thank you for choosing funEstuff! ALL funEstuff subscribers are entitled to a FREE SAMPLE ISSUE of "The Business Builder" magazine. Simply visit us at http://www.tssolutions.com/freesamp.htm for your free copy, today! -------- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Total Success Solutions, Inc believes in and supports the responsible use of bulk email advertising to targeted audiences. All remove requests are handled within 72 hours Changes to your marketing preferences can be made by visiting http://www.tssolutions.com/funestuf.htm at any time. For more information on advertising to this list or to report any problems you may be having, visit us on the internet at http://www.tssolutions.com/ or call us at 409/788-5867. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0

Re:
by Gerald Andrew Winters 19 May '98

19 May '98

Hello Daniel, So the person who withdrew the route can be different from the person who submitted the change? I assume that is the reason for adding an email address to withdrawn. But is this a likely scenerio, that of the submitter of the change being different from the withdrawer? --jerry > Gerald Winters <gerald(a)merit.edu> writes: > Hello All, > > Does someone from Ripe know the story on the "withdrawn" > attribute for route objects? The value in the v2 ripe > shows date plus email address whereas v1 had date only. > > 1. What is the rationale for the change? To be able to document who withdrew the route. > > Thanks, And what was 2? Daniel

1 0

Dare To Become A Millionaire!!
by success＠highpro.com 15 May '98

15 May '98

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ We appreciate your Subscription to funEstuff! If you would like to cancel your membership, simply REPLY to this Email with the word "REMOVE" in the SUBJECT Line. Our Automated System will delete your address immediately! If you prefer to have your remove request handled by a human, feel free to forward this entire email to us at "remove(a)tssolutions.com". We appreciate your patronage. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Dare to become a Millionaire within a year or less! This new Perpetual Leverage system developed by the Millionaire Makers Foundation is second to none. We are in the business of creating Millionaires.... honestly,quickly,legally and most of all Easily !! Perpetual Leverage generates income so fast.. after the first benefactor is enrolled you are then in a pay situation! Most are achieving $1,000.00 U.S a day within 4-8 Weeks ! Money is paid every week by blank money orders. Computer tracking system second to none. This organization is going to blow the top off of all other MLM out there. Has Only been out about 20 weeks...WorldWide. Now is the time to take advantage of this Opportunity of the Century! Especially if you already have an established downline. Get Excited its as easy as giving out a phone number.... the rest is done by the organization with full support! Don't wait jump in Now ! We will teach you the beliefs, attitude and thinking needed in becoming extremely wealthy and not only that your Whole well being will change Forever ! Check out my website at http://www.ogopogo.com/millions and take the first step to the greatest opportunity of this Century! Don't miss out.... -------------------------- Thank you for using funEstuff for your bulk mail information source! Remember... all subscribed members qualify for a FREE SAMPLE Issue of "The Business Builder" magazine. Send your name, address, and phone number to: magazine_offer(a)TheOffice.NET Your FREE, NO OBLIGATION, copy will be mailed to you, asap! -------------------------- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Total Success Solutions, Inc believes in and supports the responsible use of bulk email advertising to targeted audiences. All remove requests are handled within 72 hours Changes to your marketing preferences can be made by visiting http://www.tssolutions.com/funestuf.htm at any time. For more information on advertising to this list or to report any problems you may be having, visit us on the internet at http://www.tssolutions.com/ or call us at 409/788-5867. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0

db-wg minutes ripe-29
by Wilfried Woeber, UniVie/ACOnet 13 May '98

13 May '98

The following was waiting on top of more than one desk (on mine eventually ;-) - again causing undue delay. Please accept my apologies. Wilfried. ------------- Cut along the dotted line ----------------- Database Working Group Minutes of meeting, 28th January, 1998 at RIPE XXIX, Amsterdam, Kingdom of the Netherlands. (!!! => Action Point). The meeting began at 14:00. Wilfried Woeber chaired. 1. Administration. AMRM acted as scribe. JS sent unsolicited (but not unwelcome :-) ) notes to WW and AMRM after the meeting. CO agreed to become scribe while AMRM was swapped out to give a presentation. The proposed agenda, circulated previously, was agreed; no changes were made. The draft minutes of DB WG at RIPE 28 had been previously circulated. Comments were welcome on the mailing list. 2. The RIPE Database; an update on NCC activity. (A.M.R. Magee) Person & role data on the ftp site -> now controlled by an AUP => restricted access, still available on request, but based on an agreement with RIPE NCC, signed by a contact person. New release of the RIPE DB software v.2.1.1 available, runs on perl 5.004 RPSL -> report to Routing Wg DSTF (DB Sec Task Force)- > report to plenary Some bug fixes -> route object bug fixed New DB Code - design has begun - current functionality, new code - scalability - report from Maldwyn Morris later DB Consistency Project - State of the Database Reports -> report from the students later - Prevention -> new syntax checks; being implemented - Clean Up -> user education, new tools to be published State of DB reports - feedback welcome -> frequency, appearance, ..... Database Statistics - number of DB objects is doubling approximately every 8 - 10 months; - now 750K objects - number of DB updates slowly increasing, with major spikes every 6 - 8 months -> possibly TLD administrators doing a "clean-up" - number of DB queries gradually increasing, the growth is modulated by a short-term (~ 2 months) fluctuation now more than 2.2 x 10E6 queries per month ripe-dbm - mail bounces make the most mail -> new objects created in the DB -> these objects have a "notify" attribute which references an e-mail address which is not set up -> mail bounce to <ripe-dbm(a)ripe.net> - users are asking <ripe-dbm> for help before reading ripe-157 (AMRM swapped back into scribe). * DB consistency project; State of the DB Reports - WW introduced Kurt Dirnbauer and Horst Koenigshofer; he explained their role in the RIPE NCC as stagiares from the FS, Wiener Nieuwstadt. What is the DB consistency project ? Kurt Dirnbauer briefly described the RIPE Database Consistency Project, refering to the report written by students from the Vrij Universiteit van Amsterdam (and described by CO at the DB WG at RIPE 27). He said that the goal of this project is to remove the inconsistencies in the Database; e.g. make person references more reliable He pointed out that the RIPE DB is not a commercial DB; it is a "hand-built" database. This has advantages (e.g. portability) and disadvantages (not relational). He then showed an example of a State of the Database Report and a graph of one of the tables of data (using sample data). Technical Details Horst Koenigshofer then discussed the details of his program. This program takes the data and index files of the RIPE DB as input. It appends its output to existing files which contain the output from a previous run of the program. These files contain the numbers of each type of inconsistency. He said that at present, when there are 750K objects in the DB, that his program needs approx 4hrs on a PC (133 Mhz, 2 GB disc, 32MB RAM). Thus, his program will need 12 hours when there are 2 x 10E6 objects in the DB next year. Thus, improvements are planned: rewrite part of program and/or upgrade the hardware. Christian Halbe asked about the use of the output of the State of the DB reports. CO replied that reports to individual object managers would be available in the future. CO went on to say that clean-up tools for objects managers would be provided; the problem of who has the authority to change invalid objects would be addressed. Christian Halbe asked about plans to prevent further pollution of the RIPE Database. CO said that new syntax checks are defined; they will be implemented. WW asked whether the problems were because of structural inconsistencies or restricted modifications ??? Carsten Schiefner asked whether or not open access to the DB should be disallowed i.e. why should anyone with an e-mail address be able to create/update/delete objects ? WW replied ??? CO said that there existed an authorisation model for registering domain objects and IP address assignments; currently, a model is being developed for the Routing Registry. Thus, if all three models are in place, a general model for authorising DB updates could be deployed. WW pointed out that the modification of existing objects can be controlled and suggested that we make this mechanism more secure. There is already some control with the "mnt-lower" attribute. However, there is no control on the creation of person or role objects similar to the creation of a mntner object (which requires the manual intervention of the RIPE NCC). In the past, _everyone_ was welcome to register useful data in the RIPE DB. Should this change now ? * DB software Re-Engineering Maldwyn Morris, RIPE NCC discussed the existing code of the RIPE DB and outlined proposals for re-engineering it. He described the current system as one with well known interfaces, heavily used and "it works, but ....". He outlined the problems with the code: it is unspecified, undocumented, under commented, messy, and based on the functionality of perl4; i.e. the excellent new feature available in PERL5 are not used. He went on to say that the new version will be carefully planned: the code will be specified, documented and commented. API layers will be specified which will be coded in an appropriate language. External software (e.g. a database engine) will be used where appropriate. He described the workplan to develop this new software, but stressed that the existing functionality will be preserved; the goal here is not to introduce new functionality, but to make it easy to do so. AMRM pointed out that the software was specified in RIPE documents. MM replied that the functionality of the existing code was often different from the specification in the RIPE documents. Jake Khoun asked about goals for optimisation, e.g. increased speed. MM said that such improvements were under consideration. Jake Khoun suggested that Merit and RIPE NCC might combine appropriate pieces of DB software. Both he and MM agreed to continue the discussion off-line. CO stressed that this what was being dsicussed was new code with existing functionality; the RIPE NCC would continue to add new functionality to the existing code. WW commented that the existing code _is_ working and still performing satisfactorily. He himself would like to see a commercial database with the facility for shadow copies, ftp-copies etc. available all over Europe. He remarked how the NCC had reached the limit, in terms of volume, of the existing code. These limits are set by PERL and the operating system. It was pointed out that other organizations use similar code and link in external software. The NCC will consider this. * Other Developments !!! Jake Khuon and WW agreed to send a proposal for specifying new functionality to the RIDE mailing list. Jake indicated that the RIPE NCC code was used, but with a small modification to the process of handling as-macro objects. He went on to say that Cengiz had promised that the new version of the RA Toolset will support this. !!! Jake promised to send another pointer to the mailing list saying where the documents about this exist. CO remarked that the RIDE project had stopped, and with it a way to formulate the exchange of database information. Thus the IP registries are unable to exchange data. There is a major problem with the RIPE NCC being able to exchange data with ARIN; this problem may be solved at the level of an IETF WG or direct contact between IP registries. * Proposal for online registration of person objects (or role objects) to be done during a DNS domain registration (WW was swapped out of the chair to give a presentation on this topic; CO was swapped into the chair). The overall goal is to register a DNS domain. Currently there are two ways to do it, both are clumsy. The first method involves do some processes locally: e.g. rip apart the request for a domain and get the person object; then check if the person object is in the RIPE database. The new concept: do not mix DNS domain registration, and person/role registration. Start with person/role objects. Then submit domain object (or inetnum, or whatever), i.e. the referenced objects first, then the referencing objects. Currently, the only interface to the RIPE DB is based on e-mail. This is store and forward => slow (unreliable ?). The proposal on the table is to replace (or supplement ?) the e-mail interface with a process that will generate an new nic-hdl immediately. I.e. a separate communication path between update machine of the RIPE DB, and some application at the user side. So no disruption during the overall registration process occurs. This should include syntax checks and semantic checks (distributed, i.e. not only at the RIPE DB site, but also locally). There should at least be support for security, even if it is not implemented: - checks on the identity of the person sending in the update - responses should be signed - before anyone can use this path, they must first make a case to the RIPE NCC. WW felt that these three security checks were going to come anyway. WW presented this technical proposal and showed a sketch of the outline of the process. He pointed out that local checks could be implemented in the client. rough sketch: client local server DB master java-script <----> cgi bin <----> DB software local http tcp Most of the analysis done at the local side, additional testing done by the RIPE DB. WW said that some developement work had been done; a Java applet had been developed (for the client). Prototypes already exist, others are invited to also use it, if the community thinks that it is worthwhile. WW then asked the group for input ..... Christian Halbe said that this system was exactly what his organisation needed. They had a similar system, but it was based on e-mail and it was slow. Achim Patzner said that this system would be too late for his organisation. CO (as temporary Chair of the WG) thanked WW for his presentation. CO went on to say that some of the security issues mentioned earlier were being addresses by the DSTF (Database Security Task Force), including the definition of a secure database. CO invited input. Overall, there was support for this idea in order to develop a simple user interface. * Input from other WGs JS summarised the result of the Routing Work Group meeting, which was held earlier that day. In particular, JS mentioned: - authorisation: discussed both at the last IETF meeting and at the Routing Working Group that morning; updates should to the database should be authenticated; - more security: misuse/malicious use should be prevented - the Routing Registry is part of the overall registry; there is security on the IP numbers, but not on route objects. - more input for Database Working Group ?? * AOB none. * Close. RIPE XXIX DB WG Action Points ----------------------------- 1/. Jake Khuon and WW agreed to send a proposal for specifying new functionality to the RIDE mailing list. 2/. Jake promised to send another pointer to the mailing list saying where the documents about the RAToolset exist. ------------------------------------------------------

1 0

RE: RIPE 30 in Stockholm
by Wilfried Woeber, UniVie/ACOnet 13 May '98

13 May '98

>Please supply me with an agenda for your working >group at the forthcoming RIPE meeting. Apologies for the delay. The following is a draft agenda for the DB-WG meeting in Stockholm next week. Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-30, May 1998, Stockholm Draft, May 12, 1998 A. Administrative stuff (Wilfried Woeber, chair, ~5min) - appointment of scribe - agenda bashing B. General DB Update (RIPE NCC, ~15min) C. DB In/Consistency efforts (RIPE NCC, ~15min) - tools for the users ? D. DB SW re-implementation (RIPE NCC, ~15min + discussion) E. RPSL trans phase II: Merit's experience (~20min) F. IRRd presentation (Jake Khuoan/Craig Labovit, Merit) G. Impact of rps-dist and rps-auth drafts on DB developments H. "role:" objects for "admin-c:"s revisited (Erik-Jan Bos, SURFnet) - proposal to allow role objects being ref.d in admin-c:s Y. Input from other WGs - t.b.d. Z. AOB WW, 12-MAY-1998 23:57:48

1 0

PDCD1
by ilupe74＠econonews.com 12 May '98

12 May '98

* NOTICE: ANSWERS ARE READ AUTOMATICALLY. - ONLY SEND US BACK THIS MESSAGE IF YOU ARE INTERESTED IN OUR JOURNAL. IF YOU WISH TO RECEIVE "BREAKFAST AND DIAMONDS" IN SPANISH, INDICATE IN THE E-MAIL SUBJECT: ES (e.g.: DCD1ES) - IF YOU SEND US BACK THIS MESSAGE MORE THAN ONCE, "BREAKFAST WITH DIAMONDS" WILL BE FORWARDED AS MANY TIMES AS YOU HAVE SENT IT. *ATENCION: LAS RESPUESTAS DE ESTE E-MAIL SE LEEN AUTOMATICAMENTE. - SOLO DEBERA REBOTAR ESTE MENSAJE EN CASO DE ESTAR INTERESADO EN NUESTRO PERIODICO. SI QUIERE RECIBIR "DESAYUNE CON DIAMANTES" EN ESPAÑOL AÑADA EN EL ASUNTO LA ABREVIATURA: ES (EJ.DCD1ES). - SI REBOTA MAS DE UNA VEZ ESTE E-MAIL LE ENVIAREMOS "DESAYUNE CON DIAMANTES" TANTAS VECES COMO LO HAYA REBOTADO. Dear Sir/Madam, Would you like to have breakfast with diamonds? You probably think that this only happens in movies. However, our wish is to make your dreams come true and that you have breakfast while reading the hottest economic news in "Breakfast with Diamonds". "Breakfast with Diamonds" is an ALIVE JOURNAL, since news are hourly updated, INTERACTIVE, since our subscribers have the opportunity to ask for further information of any piece of news (free service), and GLOBAL since it includes the most significant news worldwide. INFORMATION IS KNOWLEDGE AND KNOWLEDGE IS POWER If you wish to learn more about "Breakfast with Diamonds" we cordially invite you to visit our website: http://www.econonews.com If you wish to receive "Breakfast with Diamonds" for a free 30-day trial, you just have to send us back this message. Sorry for any inconvenience we may have caused you and thank you for your time. Yours faithfully, Breakfast with Diamonds Marketing Director

1 0

None
by 337788n2 20 Apr '98

20 Apr '98

Authenticated sender is <337788n2(a)msn.com> Subject: 4-20 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: 7 Email address lists export in many different formats (HTML, Comma delimited, text file) 7 Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom 7 Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped.

1 0

auto-dbm
by RIPE Database Administration 06 Apr '98

06 Apr '98

Dear Colleagues, There is a problem with auto-dbm today. We are working to fix it, but there will be a delay before your mail is processed. If you have already sent an update, it is in the queue and it will be processed. Thank you for your patience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Advertisement: Website Hosting
by info＠inexchange.net 26 Mar '98

26 Mar '98

http://www.inexchange.net info(a)inexchange.net InExchange would like to introduce our complete Hosting and Promotional service. FOR ONLY $19.95 PER MONTH ! * 20 MB (megabytes) of disk space * 750 MB of data transfer per month * 5 E-mail accounts * INTERNATIONAL Hosting * Access to your account anytime via the Web Control Panel * Full MS Front Page support * Unlimited FTP updates * Personal CGI directory for your own scripts (or use ours) * The best statistics analyzer in the industry * E-mail forwarding, auto responders and vacation reply * Domain name registration (www.yourname.com) * FREE registration of your domain with over 250 search engines * Real Audio/Video support * Inquire about our $16.95 plan * Other plans also include: Shopping cart application and database access/utilities Cold Fusion Hosting CyberCash, iBill and VersaNet ready Instant on-line credit card processing For additional details, please refer to our website: http://inexchange.net info(a)inexchange.net

1 0

performance patch
by Curtis Villamizar 19 Mar '98

19 Mar '98

I hope this is the right place to send a tiny patch. In any case, this minor recoding makes the syntax check go a whole lot faster. Curtis Index: src/syntax.pl =================================================================== RCS file: /usr/local/CVS-routing-dev/irr-source/dbase/src/syntax.pl,v retrieving revision 2.4 diff -c -r2.4 syntax.pl *** syntax.pl 1997/11/14 20:49:12 2.4 --- syntax.pl 1998/03/17 19:59:25 *************** *** 490,501 **** # # Now check the actual keywords # ! while($tmppol =~ s/(\S+)//) { ! if (!&isaskeyword($1)) { ! return $O_ERROR, ! "syntax error in \"$ATTL{$key}: peer $as cost $pref\"\n\t$1 ". ! ! "is not a routing policy KEYWORD"; } } return $O_OK; --- 490,501 ---- # # Now check the actual keywords # ! local($tmpword); ! foreach $tmpword ( split("\\s+", "$tmppol") ) { ! if (!&isaskeyword($tmpword)) { ! return $O_ERROR, ! "syntax error in \"$ATTL{$key}: peer $as cost $pref\"\n". ! \t$tmpword is not a routing policy KEYWORD"; } } return $O_OK;

6 8

auto-dbm "bad hair day".
by RIPE Database Administration 03 Mar '98

03 Mar '98

Dear Colleagues, There is a significant delay with <auto-dbm> today. This is due to a rare combination of events which have caused a heavy demand for resources. We have taken steps to improve the situation, and I do expect the situation to improve, although not as fast as I would like. Your updates are currently being queued and eventually they will be processed in the order in which they were delivered. However, some users continue to send very large updates during office hours and this slows the entire system down for everyone. I realise how important this is to you and that it is inconvenient. I take a personal pride in the speed at which auto-dbm responds and I wish to assure you that we are doing everything possible to restore the service to its usual level. Thank you for your patience today. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

None
by LOPEC, S.L. 14 Feb '98

14 Feb '98

Muy Sr. nuestro: Solicitamos su atención para presentarle nuestra publicación semanal "Confidencial de Economia, Negocios y Bolsa" En ella encontrara junto a noticias y comentarios de actualidad tratados con un rigor, profundidad y seriedad difíciles de hallar en otras publicaciones de difusion masiva, otras secciones de gran interes profesional referidas al mundo de los negocios, tales como oportunidades, ofertas y demandas de empresas extranjeras interesadas en encontrar socios españoles o viceversa, concursos, licitaciones tanto a nivel autonomico como nacional y comunitario, asi como una extensa referencia al mundo de la Bolsa, con especial informacion de las apuestas mas osadas (compras y ventas) de la semana. En el caso de que, como esperamos, sea de su interes conocer la publicacion, adjunto a la presente le adelantarnos el sumario, al tiempo que le ofrecemos la posibilidad de que pueda recibir gratruitamente y sin compromiso la publicacion durante las cuatro proximas semanas, sin otro requisito que faciltarnos los datos que le solicitamos al final de la presente para poder asi cumplimentar el envio. Atentamente, CONFIDENCIAL DE ECONOMIA Y BOLSA ref: CNN98 NOMBRE: DOMICILIO: DP-POBLACION PROVINCIA PAIS ACTIVIDAD TELEFONO E-MAIL

1 0

Re: Efficent allocation of sub blocks from a CIDR allocation
by Mike Norris 10 Feb '98

10 Feb '98

> Have you looked at TREE? > There ought to be a valid pointer from teh NAP page. Try ftp://ftp.bt.net/pub/networking/tools/tree/tree-2.1.5.tar.Z Mike

2 1

Efficent allocation of sub blocks from a CIDR allocation
by Mark Prior 10 Feb '98

10 Feb '98

Does anyone have any suggestions, or example code, on how to handle allocation of sub blocks from a CIDR allocation. Previously Connect has allocated a /24 as the minimal block but now the APNIC have advised that they do not consider this allocation policy to be efficent as defined by RFC 2050 and so I am trying to recode our procedures. I would like to find (or else write) some code that will "optimally" allocate sub blocks and generally manage our allocation (so I can return blocks to the pool when customers leave etc). For routing convenience (optimisation) I would like to also collect together sub /24 allocations for specific POPs so that we don't need to announce all the sub /24 blocks to multihomed customers, peers and providers. Any ideas? Or pointers to other people to ask (the APNIC have been silent on the issue after requiring us to do it before they will issue us another block). Mark.

2 1

at last: minutes for the September'97 DB-WG meeting
by Wilfried Woeber, UniVie/ACOnet 21 Jan '98

21 Jan '98

At last here are the draft minutes for the DB-WG meeting during RIPE-28 in Amsterdam. Thanks to Mike Norris for taking notes and for providing me with the file shortly after the meeting. The delay is exclusively my fault, 'cause I wanted to fix a broken name and a few other things - but didn't get aroud doing it in time. Eso es la vida... Apologies for the delay, and comments, corrections, etc. welcome as ususal. Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ D R A F T D R A F T D R A F T Database Working Group Minutes of Meeting, 24th September 1997 at RIPE 28 in Amsterdam The meeting began at 16:00. Wilfried Woeber chaired. 1. Admin Stuff Mike Norris acted as scribe. An agenda of business, as circulated, was agreed. The draft minutes of the DB WG meeting at RIPE 27 had been circulated recently. Comments and corrections were welcome on the mailing list. 2. DB AUP Enforcement Carol Orange reported steps to prevent misues of the RIPE database. Responses to database queries were now prefixed with a copyright notice, with a URL for full details. Those who wished to mirror the database for local use, or to copy it for any other purpose, had to enter into a contract with RIPE NCC; this stipulated, inter alia, that the copyright notice must always be displayed in responses. The NCC was alert to abuse of the database by massive querying. 3. DB SW Status Report Ambrose Magee reported on the status of the database software. whois client - refinements to the -v flag were almost complete - the copyrigt notice (see #2 above) Ack/notification messages - these could now be suppressed RPSL - to be dealt with in a special BoF the next day DSTF - is now active - details in plenary Cross notification - now implemented - available on TEST database New software - new release soon DB consistency project - work has started - deals only with internal inconsistencies at first - three phase approach - state of DB report - prevention - cleanup of existing objects - report by Hallowe'en Statistics - 500,000+ objects - 150,000 updates in August, a peak month - 2,000,000 queries in August Ambrose reminded people to use the -k (keep session open) when making a larger number of queries in a row. Immediate plans - cross notification - DB consistency - "to do" list in line with RIPE NCC activity plan In discussion, it was reported that the NCC would undertake work on referral (to other databases) on completion of cross notification. Results could be expected by RIPE 29. Dana Hudes complained of someone else using his Graphnet trade name as a net-name in the RIPE database. It was agreed that it was not the function of RIPE to enforce any laws, nor to interfere with data entered by users in the database. 4. Registry Data Exchange (RIDE) David Kessens gave a presentation. He said that RIDE would define a standard format for Internet registries, and would define and use a protocol for exchanging and retrieving objects in such registries. A draft charter for the work was ready and there was a mailing list (subscription requests to ride-request(a)isi.edu). Status was summarised at http://www.isi.edu/~david/ride/ In discussion, David said that RIDE involved RIPE, Internic and ARIN people. An overriding goal was to make the standard as simple as possible. 5. Merit/RSng Jake Khuon reported on work being done by Merit on privacy of attributes. For example, in the inet-rtr object, rs-in: and rs-out: would be public, but contact details would be private. A new PRIV attribute applied to all objects and used the existing security model. In discussion, it was agreed that real-time editing using RA tools would be nice, but needed more authentication. 6. RAWhoisd Compatibility David Kessens reported RAWhoisd extensions. The RAToolSet didn't use all the features of RAWhoisd. He listed some of the new server features that the ToolSet needed, and also some of the outstanding requirements of the server. Performance enhancements would require a lot of effort. Wilfried would circulate Cengiz Alaettinoglu's summary to the mailing list and would invite comments. 7. Input from other WGs The Local IR WG was considering new mechanisms of allocation and reverse delegation. Due care would be exercised with any changes, particularly concerning entries in the database. The Routing WG reported that the aut-num object would have a mnt-route: attribute which would specify one or more maintainers of route objects of the same origin. The attribute would not be mandatory, though; if absent, anyone could add a route object with the aut-num as origin. Joachim Schmitz also reported that controls were still needed to effect hierarchical authorisation. 8. Activity Plan Carol Orange spoke of the RIPE NCC activity plan for 1998 insofar as it concerned work on the database. Resources had been budgetted for database security. Also, the growth of the database might lead to a requirement for new software. In these areas, she looked to the WG for support in specifying what was required. Blasco Bonito asked how many orphan person: objects there were in the database. Carol said that there were many such objects and speculated that aging might be used to help maintain the consistency of the database. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB (&NIC) Handle: WW144 --------------------------------------------------------------------------

1 0

Proposed agenda (draft) for DB-WG at RIPE-29
by Wilfried Woeber, UniVie/ACOnet 21 Jan '98

21 Jan '98

This is the first draft agenda (proposal) for the DB-WG meeting next week. Some of the items with relevance for a broader audience are being put on the agenda for the plenary. Thus I suppose that we can finish business during the 1st of the two assigned slots. Nevertheless, there is a lot of things which could need attention, potentially by a bunch of people "representing" different WGs. Therefore I'd like to keep the 2nd slot open for last minute activities. As usual, comments, additions, etc. welcome! See you! Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-29, January 1998, Amsterdam Draft, Jan. 20, 1998 A. Administrative stuff (Wilfried Woeber, chair, 5min) - appointment of scribe - agenda bashing B. NCC Update (Ambrose Magee, 10min) C. DB Consistency: state of the database report (Kurt Dirnbauer, Horst Koenigshofer, 15min) D. DB SW Re-engineering (Mal Morris, 10min + discussion) - NCC proposal/status - new/changed functionality - user community involvment - implementation scenario(s) - application and/or environment specific aspects (exchange point administration, ...) E. Other developments - Registry data exchange (RIDE) - IRR security Y. Input from other WGs - t.b.d. Z. AOB -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB (&NIC) Handle: WW144 --------------------------------------------------------------------------

1 0

Specifying a layer-3 MLPA in the IRR
by Jake Khuon 16 Jan '98

16 Jan '98

Although I've already sent this to the routing WG mailing list, Gerald Winters suggested that the DB WG might be interested in at least the authorisation schema. I have written two draft proposals (one for RIPE-181 and the other for RPSL) on how to specify layer-3 MLPAs in the IRR. I'd like to welcome any comments. I'm including a copy of each draft below and they can also be found at: http://espresso.merit.net/~khuon/khuon-003.txt http://espresso.merit.net/~khuon/khuon-004.txt #include <khuon-003.txt> Specifying and Supporting a Layer-3 MLPA Using as-macros Jake Khuon Merit Network, Inc. Document ID: khuon-003 November, 1997 ABSTRACT This document describes a procedure and mechanism for implementing layer-3 MLPA support in the Internet Routing Registry using RIPE-181 as-macros. khuon-003.txt November, 1997 - 2 - Table of Contents 1 Introduction ................................................ 2 2 Organisation of this Document ............................... 2 3 Proposed Construction of an MLPA as-macro ................... 2 4 Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-macro ................................ 3 5 References .................................................. 5 6 Author Address .............................................. 6 1. Introduction Several exchange points are making use of Multi-Lateral Peering Agreements to simplify both layer-2 and layer-3 peering. However, there is currently no mechanism to support those agreements to simplify router configuration. The most logical vehicle for specifying such an arrangement is the as-macro which is defined in [1]. Please refer to that document for more details. In the most general case, an MLPA is an agreement signed by members who wish to participate in a mutual full-mesh peering environment. This full-mesh may inhabit both layer-2 and/or layer-3. The concern with using as-macros for specifying an MLPA is that of scope of control. This macro must be modifiable by all organisations listed in the object, but one organisation should not be able to modify an attribute which references another organisation. I would like to acknowledge the contributions made by several people during the development of this document. Abha Ahuja helped in the initial design of the prescreening authorisation mechanism and Gerald Winters provided valuable input about the security considerations of the RIPE-181 language. 2. Organisation of this Paper This paper acts as both a guideline for registering MLPA-based as-macros and provides a schema for implementing a mechanism by which to handle proper control of those objects. Section 3 provides a suggested method for construction of the as-macro. Section 4 provides an architecture to be used to control maintenance of that object. 3. Proposed Construction of an MLPA as-macro The MLPA as-macro is constructed in much the same way as any other as-macro with the exception that the specified mnt-by references a controlling body which does not belong to any one organisation khuon-003.txt November, 1997 - 3 - listed. To provide for simpler implementation of the control mechanism, it is suggested that only one aut-num be referenced in each as-list attribute. It is also suggested that no as-macros be referenced by an as-list and that naming convention be strictly adhered to which would reference an aut-num to its mntner. Example: as-macro: AS-AADSMLPA descr: MLPA participants at the AADS NAP as-list: AS4550 as-list: AS683 as-list: AS2551 as-list: AS5646 as-list: AS2685 guardian: auto-mlpa(a)ameritech.net admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 971123 source: RADB The mntner MAINT-AADSMLPA referenced above may look something like: Example: mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-macro admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 971123 source: RADB In the above examples you will notice a reference to auto-mlpa(a)ameritech.net. Behind this email address will reside the actual gateway by which each of the organisations listed in the as-lists can submit changes. The details of this mechanism will be described below in Section 4. 4. Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-macro The difficulty with using as-macros to specify an MLPA is the inability to implement a distributed and scoped authorisation mechanism for a single object. This document proposes a workaround by which an automated mailing list feeds a preprocessor that in turn will pre-authorise any object submissions before it itself submits the object through the traditional auto-dbm processor. Using the example above, auto-mlpa(a)ameritech.net is authorised to submit changes to AS-AADSMLPA. The auto-mlpa(a)ameritech.net mail khuon-003.txt November, 1997 - 4 - alias should point to a process which examines the submitted object and performs the following actions in the following order: 1. Determine the difference between the submitted object and current object. It should categorise these differences as one of the following operations: A. Addition of a new as-list B. Deletion of a current as-list If the submitted object contains an addition, it is advised that an as-macro containing a list of all the organisation's ASes present at that exchange point be further interrogated to determine if the addition may proceed. This is to prevent someone from just simply adding bogus ASes to the as-macro. 2. Interogate the aut-num reference listed in the as-list and determine via that aut-num's mnt-by if the submitter of the object is authorised. 3. Extract the object from the original email submission and resubmit it to the auto-dbm process of the database using the authentication method listed in the mntner of the as-macro (PGP signed in the above example). The following outlines an example of the process architecture: Suppose AS61234 (bogus.com) wishes to add itself to the AS-AADSMLPA macro. The submitter at AS1234 would submit a copy of the changed as-macro to the auto-mlpa preprocessor/gateway... v===============================================v as-macro: AS-AADSMLPA descr: MLPA participants at the AADS NAP as-list: AS4550 as-list: AS683 as-list: AS2551 as-list: AS5646 as-list: AS2685 as-list: AS61234 guardian: auto-mlpa(a)ameritech.net admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 971123 source: RADB ^===============================================^ | | | [pgp -sta -u noc] [(sign via PGP) ] | +------------------- <noc(a)bogus.com> khuon-003.txt November, 1997 - 5 - | | | v [ -- auto-mlpa -- ] [1. Identified: add AS61234] [2. Query aut-num's mnt-by ] ????? ? ? ? v===============================================v aut-num: AS61234 descr: Bogus Organisation descr: Snerd Inc. as-in: from AS-AADSMLPA 100 accept ANY as-out: to AS-AADSMLPA announce AS61234 admin-c: Alonzo Snerd tech-c: Alonzo Snerd notify: noc(a)bogus.com mnt-by: MAINT-AS61234 changed: noc(a)bogus.com 970727 source: RADB ^===============================================^ | | | [3. Query mntner ] <---+ ? ????????????????????????????? ? ? ? v===============================================v mntner: MAINT-AS61234 descr: People authorised to make changes for AS61234 admin-c: Alonzo Snerd upd-to: noc(a)bogus.com mnt-nfy: noc(a)nogus.com auth: PGP-FROM noc(a)bogus.com mnt-by: MAINT-AS6234 changed: noc(a)bogus.com 970727 source: RADB ^===============================================^ | | | [4. Authentication satisfied] ---+ The preprocessor checks the submission and notices an addition for AS61234. It then queries for the mntner MAINT-AS61234 and checks the auth against the submitter. If the authentication scheme is satisfied, it will submit by-proxy the request to auto-dbm (using the proper auth scheme) thorisation against the mnt-by listed in the as-macro. Since the auth attribute lists auto-mlpa(a)ameritech.net as an authorised submitter, the checks will complete and the new macro with the addition of "as-list: AS61234" will take effect in RADB. khuon-003.txt November, 1997 - 6 - [5. Submit to auto-dbm ] | | v [auto-dbm] ??????????????????????? ? ? ? v===============================================v mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-macro admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 971123 source: RADB ^===============================================^ 5. References [1] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M., Yu, J., "Representation of IP Routing Policies in a Routing Registry", ripe-181, October 1994. 6. Author's Address Jake Khuon Merit Network Inc. Bldg. 1, Ste. C2122 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 USA +1 (313) 763-4907 khuon(a)Merit.Net khuon-003.txt November, 1997 #endinc /* khuon-003.txt */ #include <khuon-004.txt> Specifying and Supporting a Layer-3 MLPA Using as-sets Jake Khuon Merit Network, Inc. Document ID: khuon-004 December, 1997 ABSTRACT This document describes a procedure and mechanism for implementing layer-3 MLPA support in the Internet Routing Registry using RPSL as-sets. khuon-004.txt December, 1997 - 2 - Table of Contents 1 Introduction ................................................ 2 2 Organisation of this Document ............................... 2 3 Proposed Construction of an MLPA as-set ..................... 2 4 Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-set .................................. 3 5 References .................................................. 5 6 Author Address .............................................. 6 1. Introduction Several exchange points are making use of Multi-Lateral Peering Agreements to simplify both layer-2 and layer-3 peering. However, there is currently no mechanism to support those agreements to simplify router configuration. The most logical vehicle for specifying such an arrangement is the as-set which is defined in [1]. Please refer to that document for more details. In the most general case, an MLPA is an agreement signed by members who wish to participate in a mutual full-mesh peering environment. This full-mesh may inhabit both layer-2 and/or layer-3. The concern with using as-sets for specifying an MLPA is that of scope of control. This macro must be modifiable by all member organisations listed in the object, but one organisation should not be able to modify an attribute which references another organisation. I would like to acknowledge the contributions made by several people during the development of this document. Abha Ahuja helped in the initial design of the prescreening authorisation mechanism and Gerald Winters provided valuable input about the security considerations of the RIPE-181 and RPSL languages. 2. Organisation of this Paper This paper acts as both a guideline for registering MLPA-based as-sets and provides a schema for implementing a mechanism by which to handle proper control of those objects. Section 3 provides a suggested method for construction of the as-set. Section 4 provides an architecture to be used to control maintenance of that object. 3. Proposed Construction of an MLPA as-set The MLPA as-set is constructed in much the same way as any other as-set with the exception that the specified mnt-by references a controlling body which does not belong to any one organisation khuon-004.txt December, 1997 - 3 - listed. To provide for simpler implementation of the control mechanism, it is suggested that only one aut-num be referenced in each members attribute. It is also suggested that no as-sets be referenced by a members attribute and that naming convention be strictly adhered to which would reference an aut-num to its mntner. Example: as-set: as-aadsmlpa descr: MLPA participants at the AADS NAP members: AS4550 members: AS683 members: AS2551 members: AS5646 members: AS2685 admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 19971123 source: RADB The mntner MAINT-AADSMLPA referenced above may look something like: Example: mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-set admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 19971123 source: RADB In the above examples you will notice a reference to auto-mlpa(a)ameritech.net. Behind this email address will reside the actual gateway by which each of the organisations listed in the memberss can submit changes. The details of this mechanism will be described below in Section 4. 4. Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-set The difficulty with using as-sets to specify an MLPA is the inability to implement a distributed and scoped authorisation mechanism for a single object. This document proposes a workaround by which an automated mailing list feeds a preprocessor that in turn will pre-authorise any object submissions before it itself submits the object through the traditional auto-dbm processor. Using the example above, auto-mlpa(a)ameritech.net is authorised to submit changes to as-aadsmlpa as-set. The auto-mlpa(a)ameritech.net mail alias should point to a process which examines the submitted object and performs the following actions in the following order: khuon-004.txt December, 1997 - 4 - 1. Determine the difference between the submitted object and current object. It should categorise these differences as one of the following operations: A. Addition of a new members B. Deletion of a current members If the submitted object contains an addition, it is advised that an as-set containing a list of all the organisation's ASes present at that exchange point be further interrogated to determine if the addition may proceed. This is to prevent someone from just simply adding bogus ASes to the as-set. 2. Interogate the aut-num reference listed in the members and determine via that aut-num's mnt-by if the submitter of the object is authorised. 3. Extract the object from the original email submission and resubmit it to the auto-dbm process of the database using the authentication method listed in the mntner of the as-set (PGP signed in the above example). The following outlines an example of the process architecture: Suppose AS61234 (bogus.com) wishes to add itself to the as-aadsmlpa macro. The submitter at AS1234 would submit a copy of the changed as-set to the auto-mlpa preprocessor/gateway... v===============================================v as-set: as-aadsmlpa descr: MLPA participants at the AADS NAP members: AS4550 members: AS683 members: AS2551 members: AS5646 members: AS2685 members: AS61234 admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 19971123 source: RADB ^===============================================^ | | | [pgp -sta -u noc] [(sign via PGP) ] | +------------------- <noc(a)bogus.com> | | | v [ -- auto-mlpa -- ] khuon-004.txt December, 1997 - 5 - [1. Identified: add AS61234] [2. Query aut-num's mnt-by ] ????? ? ? ? v========================================================v aut-num: AS61234 as-name: bogus descr: Bogus Organisation import: from as-aadsmlpa action pref=1; accept ANY export: to as-aadsmlpa announce AS61234 admin-c: Alonzo Snerd tech-c: Alonzo Snerd notify: noc(a)bogus.com mnt-by: MAINT-AS61234 changed: noc(a)bogus.com 19970727 source: RADB ^========================================================^ | | | [3. Query mntner ] <---+ ? ? ? ????????????????????????????? ? ? ? v===============================================v mntner: MAINT-AS61234 descr: People authorised to make changes for AS61234 admin-c: Alonzo Snerd upd-to: noc(a)bogus.com mnt-nfy: noc(a)nogus.com auth: PGP-FROM noc(a)bogus.com mnt-by: MAINT-AS6234 changed: noc(a)bogus.com 19970727 source: RADB ^===============================================^ | | | [4. Authentication satisfied] ---+ The preprocessor checks the submission and notices an addition for AS61234. It then queries for the mntner MAINT-AS61234 and checks the auth against the submitter. If the authentication scheme is satisfied, it will submit by-proxy the request to auto-dbm (using the proper auth scheme) thorisation against the mnt-by listed in the as-set. Since the auth attribute lists auto-mlpa(a)ameritech.net as an authorised submitter, the checks will complete and the new macro with the addition of "members: AS61234" will take effect in RADB. [5. Submit to auto-dbm ] | khuon-004.txt December, 1997 - 6 - | | v [auto-dbm] ??????????????????????? ? ? ? v===============================================v mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-set admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 19971123 source: RADB ^===============================================^ 5. References [1] C. Alaettinoglu. Routing Policy Specification Language (RPSL)., Internet Draft draft-ietf-rps-rpsl-03.txt, July, 1997, Work in progress. 6. Author's Address Jake Khuon Merit Network Inc. Bldg. 1, Ste. C2122 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 USA +1 (313) 763-4907 khuon(a)Merit.Net khuon-004.txt December, 1997 #endinc /* khuon-004.txt */ -- /*====================[ Jake Khuon <khuon(a)Merit.Net> ]=====================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | Vox: (734) 763-4907 Fax: (734) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/

1 0

Re: memory leak in syncdb
by Steven Bakker 10 Jan '98

10 Jan '98

>>>>> On Mon, 5 Jan 1998, "WS" == W.Sylwestrzak(a)icm.edu.pl wrote: WS> is anyone else running daily the syncdb script experiencing huge vm WS> consumption by the process ? WS> I cannot find any obvious reason for this behaviour... Syncdb -- isn't that a Perl script? What version of Perl are you running? Any Perl5 version before 5.004_04 contains memory leaks of some sort, and even 5.004_04 probably still contains some. Perl 4.036 seemed not too bad, but that's an ancient version now, so I wouldn't bet on it. Hope this helps, Steven

3 2

(no subject)
by ipopov 05 Jan '98

05 Jan '98

Dear sirs, chiefs of the enterprises! Our company "Talan" offers cooperation and services on conditions very favourable to you. The company "Talan" is engaged in the real estate (purshase, sale and rent of apartments, houses, offices, factories, shops etc.) in St.-Petersburg, Leningrad area, other regions of Russia. The firm "Talan" is large, stable and reliable real estate company of St.-Petersburg with the ramified network of branches, has high reputation at the clients, gives attention qualitative complex to service. The especial attention is given to marketing of the market of the real estate and effective advertising. The company has an opportunity decrement of legislative and tax policy, has experience of work in the international market of the real estate. The company "Talan" is situated at historical centre of St.-Petersburg, - first on beauty and in the second-largest city of Russia. Incorporated by Peter The Greate as "window in Europe", St.-Petersburg remains large cultural, scientific and technical, port and industrial, trade and business centre of Russia with the population more than 5 mln persons. Annually St.-Petersburg is visited by millions tourists and visitors from the whole world. We agree to carry sufficient expenses for search in our country of the buyer of your real estate. In case of fulfilment of the joint bargain the unit of the commission is made in a proportion 50/50%. In other cases the size of agency fee is stipulated in the contract. For operative communication and transfer of the information about the characteristics of objects, offered you, it is convenient to use channels of a network INTERNET. Vizit our site www.real.spb.ru/index_en.htm and answer us if you are interested in business in Russia. Yours faithfully General Director Kuzmin Serge Nik.

1 0

memory leak in syncdb
by W.Sylwestrzak＠icm.edu.pl 05 Jan '98

05 Jan '98

is anyone else running daily the syncdb script experiencing huge vm consumption by the process ? I cannot find any obvious reason for this behaviour... --w

1 0

Majordomo results: Re: TICKET# 009041 [Global-Marketplace]
by Majordomo＠tradinghouse.com 19 Dec '97

19 Dec '97

-- >>>> This is to confirm that your message has been received by **** Command 'this' not recognized. >>>> Island Internet's support department. **** Command 'island' not recognized. >>>> >>>> Thank you, **** Command 'thank' not recognized. >>>> Island Internet **** Command 'island' not recognized. >>>> >>>> **** No valid commands found. **** Commands must be in message BODY, not in HEADER. **** Help for Majordomo(a)tradinghouse.com: This help message is being sent to you from the Majordomo mailing list management system at Majordomo(a)tradinghouse.com. This is version 1.94.3 of Majordomo. If you're familiar with mail servers, an advanced user's summary of Majordomo's commands appears at the end of this message. Majordomo is an automated system which allows users to subscribe and unsubscribe to mailing lists, and to retrieve files from list archives. You can interact with the Majordomo software by sending it commands in the body of mail messages addressed to "Majordomo(a)tradinghouse.com". Please do not put your commands on the subject line; Majordomo does not process commands in the subject line. You may put multiple Majordomo commands in the same mail message. Put each command on a line by itself. If you use a "signature block" at the end of your mail, Majordomo may mistakenly believe each line of your message is a command; you will then receive spurious error messages. To keep this from happening, either put a line starting with a hyphen ("-") before your signature, or put a line with just the word end on it in the same place. This will stop the Majordomo software from processing your signature as bad commands. Here are some of the things you can do using Majordomo: I. FINDING OUT WHICH LISTS ARE ON THIS SYSTEM To get a list of publicly-available mailing lists on this system, put the following line in the body of your mail message to Majordomo(a)tradinghouse.com: lists Each line will contain the name of a mailing list and a brief description of the list. To get more information about a particular list, use the "info" command, supplying the name of the list. For example, if the name of the list about which you wish information is "demo-list", you would put the line info demo-list in the body of the mail message. II. SUBSCRIBING TO A LIST Once you've determined that you wish to subscribe to one or more lists on this system, you can send commands to Majordomo to have it add you to the list, so you can begin receiving mailings. To receive list mail at the address from which you're sending your mail, simply say "subscribe" followed by the list's name: subscribe demo-list If for some reason you wish to have the mailings go to a different address (a friend's address, a specific other system on which you have an account, or an address which is more correct than the one that automatically appears in the "From:" header on the mail you send), you would add that address to the command. For instance, if you're sending a request from your work account, but wish to receive "demo-list" mail at your personal account (for which we will use "jqpublic(a)my-isp.com" as an example), you'd put the line subscribe demo-list jqpublic(a)my-isp.com in the mail message body. Based on configuration decisions made by the list owners, you may be added to the mailing list automatically. You may also receive notification that an authorization key is required for subscription. Another message will be sent to the address to be subscribed (which may or may not be the same as yours) containing the key, and directing the user to send a command found in that message back to Majordomo(a)tradinghouse.com. (This can be a bit of extra hassle, but it helps keep you from being swamped in extra email by someone who forged requests from your address.) You may also get a message that your subscription is being forwarded to the list owner for approval; some lists have waiting lists, or policies about who may subscribe. If your request is forwarded for approval, the list owner should contact you soon after your request. Upon subscribing, you should receive an introductory message, containing list policies and features. Save this message for future reference; it will also contain exact directions for unsubscribing. If you lose the intro mail and would like another copy of the policies, send this message to Majordomo(a)tradinghouse.com: intro demo-list (substituting, of course, the real name of your list for "demo-list"). III. UNSUBSCRIBING FROM MAILING LISTS Your original intro message contains the exact command which should be used to remove your address from the list. However, in most cases, you may simply send the command "unsubscribe" followed by the list name: unsubscribe demo-list (This command may fail if your provider has changed the way your address is shown in your mail.) To remove an address other than the one from which you're sending the request, give that address in the command: unsubscribe demo-list jqpublic(a)my-isp.com In either of these cases, you can tell Majordomo(a)tradinghouse.com to remove the address in question from all lists on this server by using "*" in place of the list name: unsubscribe * unsubscribe * jqpublic(a)my-isp.com IV. FINDING THE LISTS TO WHICH AN ADDRESS IS SUBSCRIBED To find the lists to which your address is subscribed, send this command in the body of a mail message to Majordomo(a)tradinghouse.com: which You can look for other addresses, or parts of an address, by specifying the text for which Majordomo should search. For instance, to find which users at my-isp.com are subscribed to which lists, you might send the command which my-isp.com Note that many list owners completely or fully disable the "which" command, considering it a privacy violation. V. FINDING OUT WHO'S SUBSCRIBED TO A LIST To get a list of the addresses on a particular list, you may use the "who" command, followed by the name of the list: who demo-list Note that many list owners allow only a list's subscribers to use the "who" command, or disable it completely, believing it to be a privacy violation. VI. RETRIEVING FILES FROM A LIST'S ARCHIVES Many list owners keep archives of files associated with a list. These may include: - back issues of the list - help files, user profiles, and other documents associated with the list - daily, monthly, or yearly archives for the list To find out if a list has any files associated with it, use the "index" command: index demo-list If you see files in which you're interested, you may retrieve them by using the "get" command and specifying the list name and archive filename. For instance, to retrieve the files called "profile.form" (presumably a form to fill out with your profile) and "demo-list.9611" (presumably the messages posted to the list in November 1996), you would put the lines get demo-list profile.form get demo-list demo-list.9611 in your mail to Majordomo(a)tradinghouse.com. VII. GETTING MORE HELP To contact a human site manager, send mail to Majordomo-Owner(a)tradinghouse.com. To contact the owner of a specific list, send mail to that list's approval address, which is formed by adding "-approval" to the user-name portion of the list's address. For instance, to contact the list owner for demo-list(a)tradinghouse.com, you would send mail to demo-list-approval(a)tradinghouse.com. To get another copy of this help message, send mail to Majordomo(a)tradinghouse.com with a line saying help in the message body. VIII. COMMAND SUMMARY FOR ADVANCED USERS In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. Items in angle brackets, such as <address>, are meta-symbols that should be replaced by appropriate text without the angle brackets. It understands the following commands: subscribe <list> [<address>] Subscribe yourself (or <address> if specified) to the named <list>. unsubscribe <list> [<address>] Unsubscribe yourself (or <address> if specified) from the named <list>. "unsubscribe *" will remove you (or <address>) from all lists. This _may not_ work if you have subscribed using multiple addresses. get <list> <filename> Get a file related to <list>. index <list> Return an index of files you can "get" for <list>. which [<address>] Find out which lists you (or <address> if specified) are on. who <list> Find out who is on the named <list>. info <list> Retrieve the general introductory information for the named <list>. intro <list> Retrieve the introductory message sent to new users. Non-subscribers may not be able to retrieve this. lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "Majordomo(a)tradinghouse.com". Multiple commands can be processed provided each occurs on a separate line. Commands in the "Subject:" line are NOT processed. If you have any questions or problems, please contact "Majordomo-Owner(a)tradinghouse.com".

1 0