- db-wg - mailman.ripe.net

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

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

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

Majordomo results: TICKET# 009041 [Global-Marketplace] Free
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. >>>> >>>> If you have any other questions about this problem, or call our **** Command 'if' not recognized. >>>> technical support line, please be sure to refer to the ticket number **** Command 'technical' not recognized. >>>> that is given in the subject of this message. **** Command 'that' not recognized. >>>> >>>> When replying to messages that contain a ticket number in the subject **** Command 'when' not recognized. >>>> line, please do not remove the ticket number as this refers to this **** Command 'line,' not recognized. >>>> particular support problem. **** Command 'particular' not recognized. >>>> >>>> If you were replying to a previously opened ticket, and you have been **** Command 'if' not recognized. >>>> returned a NEW ticket number, this means the old ticket is closed and **** Command 'returned' not recognized. >>>> you have been assigned a new ticket number. **** Command 'you' 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

[Global-Marketplace] Free Subscription
by Global-Marketplace-Digest 19 Dec '97

19 Dec '97

Global-marketplace-digest is pleased to invite you to join a genuine emagazine for fresh trade inquiries worldwide from over 130 countries. Our subscribers are very serious business executives involved in all sectors of trade and industry and look forward to get new business opportunties through our digest sent by email. We monitor it very regularly and try hard to keep it open only for genuine businesses. If you are interested to subscribe you only have to send a new email message mailto:majordomo@tradinghouse.com Just write : subscribe global-marketplace-digest (DO NOT write anything else in subject or content area). If you are not sure if you wish to subscribe but want to know more details and a brief report on how to write a good trade offer/demand please write a message and mailto:majordomo@tradinghouse.com ONLY WRITE: info global-marketplace-digest Upon your message, you will receive a reply and confirmation and introduction to the digest with instructions on how to participate. If you do not wish to further receive any messages pls send a message to : nomail(a)tradinghouse.com We wish you a happy and prosperous new year if we dont hear from you. We apologize for any incovenience this mail may cause but if you are not interested please delete it. But we write you thinking you may benefit from this offer. Take care and wish you the best Global-Marketplace-digest

1 0

Lasers/Optics/Optical Tables - Save!
by K8156mpg4＠offsh1or.com 07 Dec '97

07 Dec '97

MWK INDUSTRIES SALE! JUST A QUICK LETTER TO SHOW YOU SOME LASERS- OPTICS AND OPTICAL TABLES SURPLUS THAT WE JUST RECEIVED. ITEM TRIMMU12 14 WATT ARGON LASER MADE FOR HEART SURGERY, TRIMEDYNE MODEL 900 TEMOO, POLORIZED,220VAC INPUT , WATER COOLED , FIBER LAUNCH, ALL ON ROLLAROUND CART EXCELENT FOR LAB USE, THE POWER WAS MEASURED AT 13 TO 14 WATTS. PRICE $9500 12 MONTH WARRANTEE. ITEM: COHERENT ARTICULATING ARM FROM A MODEL 451 CO2 MEDICAL LASER. ECCELLENT COND. $200 ITEM CO220A: CO2 LASER MADE BY PFIZER ,1990, FOR SURGERY, TATTOO REMOVAL ECT. 20 WATT OUTPUT , TESTED AND IN EXC. COND. 110 VAC INPUT, COST $40,000 NEW OUR PRICE 4,900. MODEL 20-C ITEM:PDA-1U1 SPECTRA PHYSICS QUANTRA RAY PULSED DYE LASER , GOOD FOR SPARE PARTS MODEL PDA-1 $500 ITEM NEWU1 NEWPORT OPTICAL TABLE 16" BY 36" 4" THICK, 1 " HOLE SPACING, COMES WITH A RUBBER ISOLATED TABLE STAND, NOT AIR SUPPORTED, $750 ITEM: HEPSN1 HELIUM NEON POWER SUPPLY KIT OPERATES UP TO A 15 mW LASER, INCLUDES ALL COMPONENTS AND PRINTED CIRCUIT BOARD, ALL YOU HAVE TO DO IS STUFF AND SOLDER THE CIRCUIT BOARD . 4" BY 3" BY 3", PRICE $75 ITEM HENEU12 1 TO 1.5 MW HE-NE LASER 632.8 nM INCLUDES 12VDC INPUT POWER SUPPLY ALL IN A PLASTIC HOUSING 6.25 IN. BY 1.375IN BY 2.25 IN. TEMOO,RANDOM POL. ,1.7 MR DIVERGENCE. 12 MONTH WARRANTEE , PRICE $45 ITEM MELU12 1 TO 2 mW HE-NE LASER 632.8 NM , PULLS FROM MEDICAL EQUIPMENT .EACH UNIT INCLUDES HE-NE HEAD AND POWER SUPPLY[110VAC INPUT]. ALL YOU NEED TO PROVIDE IS A POWER CORD AND A FUSE TO MAKE THE UNIT OPERATIONAL. THE BEAM IS TEM00, POLORIZED WE WILL COVER EACH UNIT WITH A 12 MONTH UNLIMITED HOUR WARRANTEE, EXCELLENT FOR FOR LAB OR HOME USE. NEW THESE COST APPROX. $350 OUR PRICE $85. DIMENSIONS 9.75 BY 1.25 INCHES, P.S. 4.25 BY 3.25BY 1.25 INCHES. ITEM RAMCNS1: RAMAN CELL OPTICS 308 nm AR/AR 4600 A 0=0 DEGREES 1000 MM FL. 2" DIA. NEW. ORIGINAL PRICE $520 OUR PRICE $175 ITEM TFPOLNS1: POLARIZERS , THIN FILM FOR 532 nm , NEW, ORIGINAL COST $590 EACH OUR PRICE $200 EACH 10 MM DIA. ITEM CO2OCNS1: CO2 HIGH REFECTOR AND OUTPUT COUPLER 10.5 MM DIA, OC =79%R NEW. $200 A SET. ITEM 25MNS1: DIELECTRIC BROADBAND MIRRORS 450 TO 700NM , NEW WITH PLASTIC PROTECTIVE COATINGS , 2 SIZES 25 MM SQ. AND 50 MM SQ. RECOMENDED FOR HIGHER POWER LASERS. 25MM SIZE ITEM 25MNS1 $20 50MM SIZE ITEM 50MNS1 $25 ITEM # BSDNS1: 50/50 DIELECTRIC COATED PLATE BEAM SPLITTER 630 TO 660 NM COMES IN A TRIANGLE SHAPE EACH SIDE APPROX. 1" PRICE $20 ITEM # 45NS1 45 DEGREE RED REFLECTOR , PASSES 488 TO 532NM , CAN BE USED TO COMBINE RED AND GREEN/BLUE LASERS TO CREATE A WHITE LIGHT LASER. 1" SQ. PRICE $15 ITEM# PCINS1 PLANO/CONVEX LENS COATED FOR YAG 1064NM , AR COATED, 10MM DIA. NEW, ORIG. COST $250 OUR PRICE $100 ITEM# INFILTER : INTERFERENCE FILTERS USED FOR PASSING A PARTICULAR SPECTRAL LINE , 11.8 MM DIA. CAREFULLY REMOVED FROM MEDICAL EQUIPMENT AND WRAPPED IN LENSE PAPER. THE FOLLOWING WAVE LENGTHS ARE AVAILABLE. 523.5, 547.4 , 572.1, 512.9, 550.6, 488, 505.7 nm price $20 each. FOR A COMPLETE LINE OF NEW AND USED LASERS - OPTICS -ELECTRO OPTICS- LASER SHOWS ORDER A COMPLETE CATALOG AT MWKINDUSTRIES.COM TO: ORDER GO TO OUR WEB SITE MWKINDUSTRIES.COM {SECURE ORDERING SITE} QUESTIONS OR REMOVAL FROM MAILING LIST EMAIL: MWK(a)WORLDNET.ATT.NET MWK INDUSTRIES 1269 POMONA RD CORONA CA 91720 PHONE 909-278-0563 FAX 909-278-4887

1 0

We will mail 4 U
by 73fz0Vyhp＠le1ttrbox.com 25 Nov '97

25 Nov '97

LET US DO YOUR BULK MAILINGS!!! ..$250 PER MILLION THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. Addresses are extracted daily by four of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. They are fresh! Over 36 million addresses on file. No more than 2 pages (50 lines), no porn and no foul language. We do not do targeted mailings at this price. Targeted mailings $150 per 50,000 addresses extracted. There are no lower prices on the net. Your mailing can be done in a matter of hours. We have 4 computers extracting addresses 24/7. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is busy, please keep trying, as bulk mailing is growing fast. We do want to work with you to advertise your product. $250 per million expires December 1, 1997. Price increases to $350 per million, $250 per 500,000. All orders received before December 1 will not reflect the increase. Even with the increase, we will still be the best prices on the net. To have your name removed, call our processing office. Any negative responses will be dealt with accordingly.

1 0

RE: fancy route objects
by Paul Dyke 04 Nov '97

04 Nov '97

The entry by myself was generated by RIPE as an error to an email. I did try to delete it but have had no success. Can you help. Regards Paul Dyke -----Original Message----- From: Gabor Kiss (Bitman) [SMTP:kissg@sztaki.hu] Sent: 03 November 1997 12:20 To: ripe-dbm(a)ripe.net Cc: db-wg(a)ripe.net; Paul.Dyke(a)bt.net; bridge(a)unisource.ch; gaga(a)elte.hu Subject: fancy route objects Dear Colleagues, Are there these route objects correct (is this some very new feature?) or they come from some software bug? Three independent user can't get mad the same time. Note: these objects cannot be queried. I've browsed the mirrored DB file. Gabor *rt: 127.255.255.255/24 *de: TAT GmbH Systeme der grafische Datenverarbeit *or: AS2856 *mb: BTNET-MNT *ch: Paul.Dyke(a)bt.net 970916 *so: RIPE *rt: 127.255.255.255/16 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/24 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/23 *de: HU-CEU *or: AS2012 *mb: AS2012-MNT *ch: gaga(a)elte.hu 971027 *so: RIPE

1 0

IMPORTANT; Aut-num objects.
by RIPE Database Administration 03 Nov '97

03 Nov '97

Dear Colleagues, The data file and index file of the aut-num objects were corrupted this morning. This caused the aut-num objects not to be available. We regenerated the indexes. However, we discovered that some aut-num objects were missing. Thus, we rebuilt the data file using a back-up copy and generated new indexes. The aut-num objects file was reliable until 00:00 hours UTC on Monday, 3 November. The whois service was reliable again at 17:00 hours UTC this evening and the ftp copy of the aut-num objects was valid again at 20:00 hours UTC tonight. We are aware that this may have caused you some inconvenience; we therefore fixed the problem as fast as we could. If you use the data in the aut-num objects file as a basis for build routing tables or any similar purpose, we recommend that you obtain a new copy of this data from our ftp-site. Only the aut-num objects were affected this morning. The other database objects appeared not to be affected. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Re: Who should do entries in RIPE database?
by Wilfried Woeber, UniVie/ACOnet 03 Nov '97

03 Nov '97

>There is another problem too: some objects do have a mnt-by, however the >mntner has auth: NONE! :( Can we assume that these objects are well maintained? >My answer is: no. I wouldn't follow that particular line of reasoning! The fact that you/he/she/someone does not *restrict access* to objects does not mean that the maintainer does not *maintain* the objects!? I think we're still mixing aspects of - access rights to objects (=access authorization) - access rights to "registry spaces" (=object creation) - authentication & identification (=credibility of data) and last but not least - object aging and checkpointing, dangling pointers, non-ref.s, duplicates etc. >Janos > >PS. I have seen this with both inetnum and route objects. Wilfried.

1 0

fancy route objects
by Gabor Kiss (Bitman) 03 Nov '97

03 Nov '97

Dear Colleagues, Are there these route objects correct (is this some very new feature?) or they come from some software bug? Three independent user can't get mad the same time. Note: these objects cannot be queried. I've browsed the mirrored DB file. Gabor *rt: 127.255.255.255/24 *de: TAT GmbH Systeme der grafische Datenverarbeit *or: AS2856 *mb: BTNET-MNT *ch: Paul.Dyke(a)bt.net 970916 *so: RIPE *rt: 127.255.255.255/16 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/24 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/23 *de: HU-CEU *or: AS2012 *mb: AS2012-MNT *ch: gaga(a)elte.hu 971027 *so: RIPE

2 1

Re: Who should do entries in RIPE database?
by zsako＠banknet.net 03 Nov '97

03 Nov '97

> From owner-db-wg(a)ripe.net Mon Nov 3 11:27:09 1997 > > What about creating two databases? (Two categories of objects.) > > One for objects sent by non-registries, > > and one for well maintained, authentic objects. > > This may be an orthogonal categorization. Sorry, but many of the duplicates > (triplicates ...) already carry the "mnt-by" attribute, sometimes > even two instances the same one. There is another problem too: some objects do have a mnt-by, however the mntner has auth: NONE! :( Can we assume that these objects are well maintained? My answer is: no. Janos PS. I have seen this with both inetnum and route objects.

1 0

Re: Who should do entries in RIPE database?
by Gabor Kiss (Bitman) 03 Nov '97

03 Nov '97

> - Last but not least we could think about "closing" the DB for public, > that is anonymous, update or registration of objects. I think *that* > would require *very* careful consideration, discussion, and > establishing a broad consensus across (all of) the RIPE-WGs. > I'd also expect considerable impact on activities like RIDE. I got further (not too serious) ideas: What about creating two databases? (Two categories of objects.) One for objects sent by non-registries, and one for well maintained, authentic objects. Peoples could send objects to the level1 database, and registries could move the correct ones to level2. Level1 objects older than 6 months will be automatically and silently deleted. Level2 objects should be updated at least once a year, otherwise a warning message goes to the maintainer registry. After a certain period forgotten level2 objects go back to level1. All current object is on level1. Regards Gabor

2 1

Re: Who should do entries in RIPE database?
by Wilfried Woeber, UniVie/ACOnet 31 Oct '97

31 Oct '97

Folks, thanks for bringing this up for discussion! >The other point is to prevent the RIPE database from further pollution. >There should be some settings to guarantee this. What is your opinion: >should I post my suggestions just to 'lir-wg(a)ripe.net'and 'db-wg@ >ripe.net' or in addition also to 'local-ir(a)ripe.net'? I'll try to summarize from my point of view (both as DB-WG chair, Local-IR rep and of course as a dumb user :-) We have long since worked from the assumption that the "owner" of an object is responsible for it's on-going maintenance. We have always felt, that tigthening the rules too much would have a negative impact on all parties' willingness to register (at all) or to perform updates regularly. Then we introduced measures to protect *existing* objects by limiting the sources where updates (+ deletes :-) are accepted from (maintainer mechanism). This is particularly relevant for the IP Registry and for the Routing Registry. The next step has been protection of hierarchies in the object space with the mnt-lower mechanism, in particular for the Domain-Registry. Right now the Routing-WG and the NCC are working on the implementation of cross-notification for the routing registry. All of these mechanism can by now (or very soon) be used to ascertain a useful level of security and update control, including the referenced objects. This leaves us with two major weaknesses - or features: - A considerable percentage of the objects is not yet protected by the mechanisms which are readily available, and "tightening" the ropes requires a more careful approach by the various registries - leading to more work, in the end. In particular if we think about "owning" and protecting the person objects as referenced by data for the various registries.... - Nothing is there to prevent *any* party to put e.g. person objects into the DB. (And I certainly appreciate that myself!) Also, I suppose some other types of objects can be put into the DB without problems, unless they are in dircet conflict with one of the well-managed object spaces for a particular registry. This leaves us with a legacy of entries from the "Dark Ages" of DB deployment and with the on-going pollution of object space by way of "user error". This aspect is being addressed by the DB-Consistency Project. We work towards offering mechanisms to identify inconsistencies as described by a "catalogue of frequent problems" as well as by coming up with the logistics to repair these deficiencies. Again, to be successful, the registries shall be required to spend (considerable?) effort to participate in that activity. So what can be done on top of that to improve the situation? - We can offer improved mechaisms to deal with identification and authentication: this is on the agenda for the DB-Security Task Force. - We can try to improve the user interface. In particular to help the end-users to avoid the popular crimes like putting in just another person object as soon as there's a new reference: We (the AT-TLD administration) are in the process of designing and prototyping an interactive interface that should prevent most of these incidents. We're in contact with the NCC to determine the usefulness of that approach. Please stay tuned. - Last but not least we could think about "closing" the DB for public, that is anonymous, update or registration of objects. I think *that* would require *very* careful consideration, discussion, and establishing a broad consensus across (all of) the RIPE-WGs. I'd also expect considerable impact on activities like RIDE. But it is certainly not impossible to get that discussion going. Although (wearing no hat at all right now :-) I do not see a pressing need right now - taking into account that we have a set of mechanisms in the works to improve the situation. Comments and input welcome! Apologies for the lengthy speech... Wilfried. -------------------------------------------------------------------------- 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