- lir-wg - mailman.ripe.net

Undeliverable Message
by MAILER-DAEMON-VINES01＠vines.is.belgacom.be 10 Nov '97

10 Nov '97

To: SMTP_GATEWAY@IS.2624225@BELGACOM[<lir-wg(a)ripe.net>] Cc: SMTP_GATEWAY@IS.2624225@BELGACOM["Hank Nussbacher" <HANK(a)taunivm.tau.ac.il>] Subject: Cost of links to US Message not delivered to recipients below. Press F1 for help with VNM error codes. VNM3043: FONTEYNE Frederic@BTB.MTM_MM1@BELGACOM VNM3043 -- MAILBOX IS FULL The message cannot be delivered because the recipient's mailbox contains the maximum number of messages, as set by the system administrator. The recipient must delete some messages before any other messages can be delivered. The maximum message limit for a user's mailbox is 10,000. The default message limit is 1000 messages. Administrators can set message limits using the Mailbox Settings function available in the Manage User menu (MUSER). When a user's mailbox reaches the limit, the user must delete some of the messages before the mailbox can accept any more incoming messages. ---------------------- Original Message Follows ---------------------- ------- Forwarded Message Received: (qmail 615 invoked from network); 10 Nov 1997 07:58:13 -0000 Received: from ncc.ripe.net (193.0.0.129) by postman.ripe.net with SMTP; 10 Nov 1997 07:58:13 -0000 Received: from taunivm.tau.ac.il by ncc.ripe.net with SMTP id AA23238 (5.65a/NCC-2.41); Mon, 10 Nov 1997 08:58:11 +0100 Message-Id: <9711100758.AA23238(a)ncc.ripe.net> Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 6715; Mon, 10 Nov 97 09:57:16 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1 .2a/1.8a) with BSMTP id 9621; Mon, 10 Nov 1997 09:57:16 +0200 Date: Mon, 10 Nov 97 09:55:40 IST From: Hank Nussbacher <HANK(a)VM.TAU.AC.IL> Subject: Cost of links to US To: local-ir(a)ripe.net Mime-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT For a lecture I am preparing I am in need of some costs. How much do you pay (can be in local currency) for a T1/E1 or T3/E3 line to the USA. Plz specify via which carrier, and what cable if possible. Thanks, Hank ------- End of Forwarded Message

1 0

Cost of links to US
by NCC local-ir list Moderator 10 Nov '97

10 Nov '97

------- Forwarded Message Received: (qmail 615 invoked from network); 10 Nov 1997 07:58:13 -0000 Received: from ncc.ripe.net (193.0.0.129) by postman.ripe.net with SMTP; 10 Nov 1997 07:58:13 -0000 Received: from taunivm.tau.ac.il by ncc.ripe.net with SMTP id AA23238 (5.65a/NCC-2.41); Mon, 10 Nov 1997 08:58:11 +0100 Message-Id: <9711100758.AA23238(a)ncc.ripe.net> Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 6715; Mon, 10 Nov 97 09:57:16 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1 .2a/1.8a) with BSMTP id 9621; Mon, 10 Nov 1997 09:57:16 +0200 Date: Mon, 10 Nov 97 09:55:40 IST From: Hank Nussbacher <HANK(a)VM.TAU.AC.IL> Subject: Cost of links to US To: local-ir(a)ripe.net Mime-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT For a lecture I am preparing I am in need of some costs. How much do you pay (can be in local currency) for a T1/E1 or T3/E3 line to the USA. Plz specify via which carrier, and what cable if possible. Thanks, Hank ------- End of Forwarded Message

1 0

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

Re: Who should do entries in RIPE database?
by Carol Orange 31 Oct '97

31 Oct '97

Dear Carsten, Yes indeed, the consistency problems in the RIPE database are well known and are even well documented in: ftp://ftp.ripe.net/ripe/dbase/info/consistency* and ftp://ftp.ripe.net/ripe/presentations/ripe-m26-orange-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-26/pres/db-consist/ Our plans to deal with them are also documented in: ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-woeber-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-27/pres/db/consistency/ We do plan to try to eliminate multiple objects pointing to the same person, as well as other clean ups of the person data. [As a side note, this project is now well underway.] We have not however discussed limiting the ability to enter data in the RIPE database, outside of the current and proposed authorization mechanisms. That would certainly be a significant change of course, and for that reason, I have cc'd the RIPE Database working group on this mail to get their feedback on this idea. Greetings, Carol Orange RIPE NCC In message <3456024C.70C28953(a)contrib.com>, Carsten Schiefner writes: >> As a result of a voluminous discussion with one of POPs I would like to >> point your interest on the following topic I am a little bit upset of: >> >> Almost everybody who knows about about the RIPE database schema (which >> is no secret at all!) can do entries just by sending a mail to >> 'auto-dbm(a)ripe.net'. This leads to an overwhelming bunch of multiple, >> bad maintained or what-ever-you-want entries - especially person >> objects - without any fun in grepping through them and selecting the >> right one to create a new object. Example: >> >> There are four(!) entries for the entity "Joerg Schmidt" of "ZWF >> Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, >> JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! >> >> My idea is that we should discuss future restrictions on the possibility >> for everybody to put entries in the RIPE database, maybe by setting up >> and maintaing access lists for every LIR. >> >> For me this database is a central tool in my daily work and I am very >> interested in keeping quality and reliability of stored data as high >> as possible. >> >> Kind regards, >> >> Carsten Schiefner >> -- >> >> Carsten Schiefner mailto:schiefner@contrib.com >> TCP/IP GmbH, Berlin (Germany) - Contrib.Net http://www.contrib.com >> Phone: +49.30.44 33 66-0 Fax: +49.30.44 33 66-15 >> ======================================================================

2 1

Remove me from email list
by Michael Johnson 06 Oct '97

06 Oct '97

Remove me from email list. Michael -- InterNex Information Services | Michael R. Johnson Network Engineering | mrjohn(a)internex.net 2306 Walsh Avenue | Tel: (408) 327-2209 Santa Clara, Ca. 95051 | Fax: (408) 496-5484 ---------- Forwarded message ---------- Date: Mon, 06 Oct 1997 12:00:27 +0200 From: Mirjam Kuehne <Mirjam.Kuehne(a)ripe.net> To: lir-wg(a)ripe.net Subject: announcements in 62/8 Dear local IRs, During the LIR WG at the RIPE Meeting two weeks ago a question came up on how many of the allocations from 62/8 are actually announced. >From a snapshot taken of our routing table on 29th Sept we could see that 37 of the 50 allocations are also announced (almost 75%). This is not bad, even though 100% would of course be better ;-) Kind Regards, Mirjam Kuehne Manager Registration Services RIPE NCC

1 0

announcements in 62/8
by Mirjam Kuehne 06 Oct '97

06 Oct '97

Dear local IRs, During the LIR WG at the RIPE Meeting two weeks ago a question came up on how many of the allocations from 62/8 are actually announced. >From a snapshot taken of our routing table on 29th Sept we could see that 37 of the 50 allocations are also announced (almost 75%). This is not bad, even though 100% would of course be better ;-) Kind Regards, Mirjam Kuehne Manager Registration Services RIPE NCC

1 0

Re: More on spamming..
by Miroslaw Jaworski 04 Oct '97

04 Oct '97

On Wed, 1 Oct 1997, Paul Thornton wrote: > I have to agree with Alex here. If we can persuade ISPs (and customers who > have mail servers which can relay) to fix their configurations to deny > relaying except for their own hosts/networks then we have made a big step > forward. but it still doesn't solve problem of spamming. MJ ___________________________________________________________________________ Miroslaw.Jaworski(a)ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division WAN/UNIX adm

11 22

Draft minutes of LIR WG at RIPE 28
by Mike Norris 03 Oct '97

03 Oct '97

Below are the draft minutes of the LIR WG mtg at RIPE 28, prepared by Anne Lord (many thanks, Anne). Corrections, comments to me, please, certainly before Hallowe'en ;-) Mike Norris D R A F T D R A F T D R A F T Local IR Working Group at RIPE 28, Amsterdam Chair: Mike Norris Scribe: Anne Lord 1. Preliminaries Mike opened the meeting and welcomed the attenders to the session. Anne Lord volunteered to be scribe. There were 70 attenders at the working group session. 2. Open action items Minutes of RIPE 27 have been circulated and corrections made. There are no open action items from the previous meeting. 3. Report from Registries RIPE NCC - Mirjam Kuehne Graph of current EU DNS hostcount shown - likely to hit 5 million before the end of the month. New staff - two new hostmasters : Julia Edwards from the US and Sabrina Waschke from Germany. Brings the total staff to 11 full time and 1 part time staff. Response time to requests is now 1 working day (for an acknowledgement). Wait queue is now growing again (additional load caused by hiring of new hostmasters). Staff getting an increased number of phone calls now with mostly IP related questions. Automation improvements have helped. Reverse delegation is now fully automated. Ticketing system improved in performance and functionality. A web interface has been developed for allowing queries of ticket status (see report by Mal Morris below). A registry now has one main handler (hostmaster) for each registry plus one or two backup handlers (hostmasters). Auditing and monitoring work extends to 3 parts: 1) Monitoring in daily work * database accuracy * complete documentation available * compliance with policies 2) Proactive Audits LIRs that they have little contact with e.g. those established for a long time will be contacted to see if they are in touch with latest procedures. 3) Audits on request If you wish to discuss procedures/practices of local IR's you can send your comments to the RIPE NCC. They will then investigate. John Crain is working on the quality initiative with respect to local IRs. Most LIRs do follow the guidelines. The main problem is due to dangling references in the RIPE db. A RIPE document is in preparation about the auditing process and the statistics found after a consistency check of the RIPE db. This is expected to be published soon after the meeting. Internal QA Internal procedures are now documented more clearly. They also have more structured staff training. Monitoring of internal database also started. LIR Training courses 5 courses have been given since the last RIPE meeting. Ukraine course was cancelled due to lack of interest. The NCC has a "no show" policy. This is as follows: New LIRs get priority in their first year; "local" LIRs get priority - 2 places per local IR. After places are used they have no priority anymore - this means either attended or not shown up. Plans and Promises Plan to continue quality activities and more resources have been added to this activity. Work flow management which is more structured will be introduced. Internal procedures will be further automated. Next LIR courses (planned) October : Paris (in conjunction with Interop) October : London November: Berlin November: Prague December: Rome They run a script to see where most new local IRs are coming from to determine city where to give training course. Slides: ftp://ftp.ripe.net/ripe/presentations/ripem28-mir-RS-REPORT.ps http://www.ripe.net/meetings/ripe/ripe-28/pre/ncc-reg APNIC Decision on city of relocation not final - but it will be in Australia. Plan to relocate involves keeping two offices - one in Tokyo for a short period of time. ARIN On course to go live in approximately 2-3 weeks time. Encountered some legal problems which are now overcome. AFRI-NIC Nothing has been formalised apart from it's principle of establishment. 4. IP Address Space Assignment Policy document revision Please note : ripe-159 is now the policy document [replacing ripe-140, which replaced ripe-104]. Accompanying documents are still ripe-141 and ripe-142. Use of class A address space Registries can have two allocations: one traditional and one from class A address space. Caveats are that you may encounter difficulties with classless routing out in the Internet. There was a question about amount allocated so far. So far about 50 ranges have been allocated. Question was asked about amount of allocations announced on the Internet, but the answer was not known. Web interface to the Ticketing System Maldwyn Morris gave a "live" demonstration of the RIPE NCC ticketing system which will shortly be available via the web pages. Check out: http://www.ripe.net/cgi-bin/rttquery Question: How much longer you have to wait in queue once handed off to hostmaster. Answer: This should not be more than one day. This information would be added to the web page. Suggestion to add name of the hostmaster dealing with your request to the web page. There was quite some discussion about this and it was not agreed to do so explicitly. Plans also to include information about closed tickets. 5. Registry procedures Suggestions to couple reverse delegations to assignments and to make this tool web based. Discussion on the list as to how to go about this. Suggestions included using "mnter" based authentication, SSL, PGP etc... Further discussions needed with the Database group on formats & mechanisms for protection. Carol gave a report on the status of IP address web allocation. Work is being done on auto-parsing the email message before it goes to the hostmaster on a sanity check on what you have sent in. Now needed is the web interface. There is still the area of security for consideration when sending in requests. So far, this has not been considered. Furthermore, we could consider functionality like if the request is accepted, to have it automatically update the RIPE database (and go further in updating reverse db?). There was quite some discussion about this but no action items emerged. So to conclude, the mechanisms for parsing are in place but are not yet released. Wilfried suggested to put security mechanisms on the "input from other working groups" so as to start a discussion and think some more about this. Tools for local registries ripe-141.{ps,txt} forms are available for use with customers of local IRs. There was a suggestion to put links from any useful web pages on tools to Local IR page and the "tools" page at the RIPE NCC. There was an action item place on Mike Norris to make this happen. (A1:28 see below). 6. Input/output with other working groups None discussed at this meeting. 7. Statistics i) Reverse DNS counts, errors are archived on RIPE web site. Blasco suggested doing some analysis of DNS reverse error counts. RIPE NCC agreed this was a good idea and at some stage was to be put on the activity plan. This was taken as an action item by the RIPE NCC. ii) Effect of NAT etc on PI address space. Diminuation of PI address space usage? Should every ISP use PI address space for multihoming? There was actually little discussion on this issue. 8. AOB i) Mailing lists Clarification of the RIPE NCC mailing lists. "Open" mailing lists are: * ripe-list(a)ripe.net * db-wg(a)ripe.net * dns-wg(a)ripe.net * lir-wg(a)ripe.net etc.. lir-wg(a)ripe.net working group is for discussions, open to anyone, not monitored right now but will be in the future. All maintained by majordomo. Blasco suggested to have a web interface to read archives of working group mailing lists [action NCC] "Closed" Mailing lists for contributors only: local-ir(a)ripe.net ncc-co(a)terena.nl Not managed by majordomo. <local-ir(a)ripe.net> is open only to contributing local IRs. Is automatically subscribed to. Used for announcements relevant to registries only. Low traffic. Is monitored to filter out spam and to deal with bounces. Requests or questions to <local-ir-request(a)ripe.net> Question of duplication was raised and how to handle it. Carol added that NCC has proposed a new activity to look at filtering out duplicate messages. Anti-Spam Spam topic related. Want to close public submission to the open lists. so that we can limit the spam. Suggestion to match against a list of domain names that mail is allowed to be posted to the list from. Geert Jan had another suggestion which involved blocking specific addresses that people spam from against a list of permitted addresses. However people can forge headers. Discussion moved to plenary and to working group lists. Suggestions to give some consideration to email discussions on this prior to the plenary discussion. Recommendation to gather together individuals that are contributing on this topic and to collate information on how to deal with Spam attacks. Daniel suggested that the local IR working group continue working on this. Mike Norris took an action to gather the various propoals on spamming and circulate to the working group list. Summary of open action items: Action 1:28 Mike Norris to put a link on the RIPE NCC web page and the working group page to useful LIR tools. Action 2:28 RIPE NCC to prepare an analysis of the reverse DNS error counts. Action 3:28 Mike Norris to collect information on anti-spamming policies and circulate to the list in a draft paper the recommendations on dealing with spam. Action 4:28 RIPE NCC to produce web interface to archives of WG mailing lists. ------- End of Forwarded Message

1 0

Re: More on spamming..
by Javier Llopis 03 Oct '97

03 Oct '97

On Wed, 1 Oct 1997 14:59:40 -6000, Miroslaw Jaworski wrote: >Cooperation of all ISP is needed. Index od spammers. >Absolute rule : before setting up new accounts, check customer in >spammers index. > >And for more : official documents about spam. It should be announced and >published over network so EVERY user can read it and imagine what >will happen with him if..... Hmmm... I think that this could be HIGHLY illegal for the following reasons: - Spamming, although annoying is not illegal (even if the only reason is that laws evolve at a very slow speed) - Putting someone in a black list can greatly affect a person's or a small company's reputation and business. Most EU national laws forbid publishing that kind of information, let alone an agreement between ISP's not to service that fellow. In addition, if all the proof you have is based in your logs, which anyone can alter just with 'vi' and imagination, it is the spammer who will sue you for huge amounts of money. Making the spammers rich is not the optimal way to stop spamming. The only legal loophole would be if ISPs put a disuasive price for spamming practices in their service contract. A price so high that no spammer would pay. Then spammers would be invoiced, and the invoice would become unpaid after the invoice due date. Publishing a list of people who won't pay you is not illegal as long as the debt is well documented (with the invoice) nor is denying service because of being on that list. (We could have legal problems anyway, but the case would be harder for the spammer) And the only way out of the list would be paying the bill. Regards Javier Llopis BitMailer, S.L. javier(a)bitmailer.com Juan Bravo 51, Dup. 1-Izq Tel: +34 1 402 1551 28006 Madrid Fax: +34 1 402 4115 SPAIN

3 2

RE: spamming
by Kevin Ferguson 03 Oct '97

03 Oct '97

Hear, hear! Over the last few days I have received more mail via this mail list than I have received from spammers! Regards, Kevin. On Thursday, October 02, 1997 5:14 PM, Maarten E. Linthorst [SMTP:mel@csi.ch] wrote: > can we please discuss spamming on different mail list. > regards > GoldNet maarten linthorst

4 3