September 1999 - lir-wg - mailman.ripe.net

RIPE Hostmasters visiting LIRs
by Sam Critchley 16 Sep '99

16 Sep '99

Hello, Recently a few colleagues and I have been talking about the way we interact with the people in the RIPE NCC when dealing with customer assignments (and some other matters). One of the things we thought could be beneficial is if Hostmasters had more experience of the kind of issues we in the ISP community face on a day-to-day basis. We thought it might be a good idea if some of the Hostmasters were able to visit an ISP and see how they work, meet the people they deal with and perhaps work alongside them for a period of time. With this in mind we first thought of inviting individual people to come and visit us, or perhaps addressing the NCC asking if this were possible. However, we soon realised that this would have neutrality implications, and that it could be damaging both to the RIPE NCC reputation and to ours, and that for this reason it was unlikely to be accepted by them. In the last week or so I've been in touch with people in several other LIRs here in the Netherlands on an informal basis, and we all seem to agree that, were visits made to multiple registries by multiple members of the staff of the NCC, then this would have fewer neutrality implications. It seems like there are several registries who would be happy to offer help with this if it has a potential benefit for all LIRs. I realise that this has been discussed in various forums before, but feel personally that we are now able to remove many of the barriers which might prevent it happening. Do other LIRs feel that this could be beneficial to everyone in the RIPE community? What do RIPE NCC staff themselves think about it? What kind of restraints do people feel should be placed upon any such scheme? How should it be organised? Should it be discussed at a meeting? Looking forward to any comments on the lir-wg mailing-list, Best wishes, Sam

7 11

Re: RIPE handles delay
by Wilfried Woeber, UniVie/ACOnet 15 Sep '99

15 Sep '99

Dear Vesa! => response to updates more directly related to the RIPE DB intended purpose => while still ensuring that others not so directly related will get => processed. = =This tactful comment probably means a turn to the right direction. =But I wish it was said loudly and clearly, maybe even as a complete =change in DB usage policy. We pay for address registration services, =please take the domain (non-rev-dns-related) objects elsewhere. To statr with I'd like to assure you that we are (sometimes painfully) aware of the issue(s) you'r point fingers at. Quite a bit of things have been achived already to allow us to move in the right direction in due time: Technically: the NCC already has implemented the WG-approved refer: attribute to allow referrals to "remote" autoritative servers for domain: objects. This is already being use by (a few) TLD registries, others are working towards that end. Logistics: CENTR was formed within the framework of the RIPE NCC quite a while ago to deal with TLD activites (or DNS issues in general). CENTR has meanwhile been incoprorated as a legal entity of it's own, and moved office to the UK. RIPE discussions: we have already (recently) started to discuss (both informally amongst the WG chairs, as well as within the various WG meetings) the issues with co-locating different registries within a single database environment (i.e. the IP-Registry, Routing-Registry, DNS-Registry). These issues are (amongst others) . authority for data and responsibility for data quality . access patterns ie.e. (updates vs. consumers, privacy, copyright) . providing operational resources As an aside, you are correct in stating that the NCC's main objective rests with the IP-Address, including reverseDNS and Routing Registry activites. But, at the same time, the creation of and support for CENTR and the DNS-related activites was agreed by the RIPE community and there was (still is?) a contract in place between the NCC and CENTR to have CENTR contribute equitably to the NCC's operational costs. I'm looking forward to continue this thread of discussion (within the DB-WG framework or somewhere else) as well as to corrections and amendments by the RIPE community and WG chairs, and/or from NCC staff. Best regards, and thanks for bringing this up (again) for consideration! Wilfried Woeber DataBase WG chair. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________

1 0

RIPE handles delay
by Alfredo E. Cotroneo 14 Sep '99

14 Sep '99

Hi, For the last ten days or so we have noticed that replies for a new contact handle to auto-dbm(a)ripe.net is taking much more than the usual 2-5 minutes as it used to be in the good old times ;-) Although we request only a few handles per month, a relly from RIPE takes now 10-20 hrs or more in some cases, regardless of the time (day or night, week or week-end) when the request is sent out. I have heard of some kind of explanation related to SW/HW upgrades at RIPE and huge requests of handles being queued by some provider a few days ago, however, can someone at RIPE tell if the situation is going to be solved soon and when ? Unfortunately this is causing at least an additional 1+ day delay in the registration of new domains at the Italian NIC, as IT-NIC requests that a handle exists for each contact before the domain registration form is submitted. Of course any comment from IT-NIC on how they can modify their internal procedures to minimize such delays (i.e. by IT-NIC requesting a new handle to RIPE directly) is also welcome. Thanks. -- Alfredo E. Cotroneo PO Box 11028, 20110, Milano, Italy Phone: +39-335-214-614 (try first) / +39-02-266-6971 email: alfredo(a)nexus.org fax: +39-02-706-38151

4 3

New RIPE NCC reverse delegation procedure
by RIPE NCC IN-ADDR. ARPA Role Account 13 Sep '99

13 Sep '99

Dear Working Group, we intend to rewrite the software that we use to automate reverse delegation requests, with the (main) goals: - simplify/improve the request procedure - maximise automation to keep resource demands reasonable e.g. improving our internal system, including, for example, IPv6 automation - improve the maintainability of the software There are several issues which come up with regard to the request procedure. I've outlined some of our *intentions* below in the hope of soliciting feedback. ---> Requesters will only need to write to a single automatic mailbox <auto-inaddr(a)ripe.net>, to request reverse delegation. Database update will take place automatically once all other checks are passed. + simplifies and speeds up procedure ---> If we attempt a zone tranfer to check that the contents of a zone are syntactically correct and consistent with other nameservers, and the transfer fails, we will not reject the request. We will check all of the data which can be queried without a transfer. + many zone administrators are very happy. - we cannot check some of the zone contents for problems. However, we think that the information we can collect without the transfers is sufficient to decide whether the delegation itself is well setup, even if it's contents are not. [Note: zone tranfers to our network will still be *required* to be enabled for reverse /16 zones, since we will continue to require that ns.ripe.net be included as a secondary for these zones.] ---> It will be mandatory that a registry ID is included in all requests for reverse delegation, as is currently the case for requests to <hostmaster(a)ripe.net>. We will require that all requests come from an LIR receiving service (i.e. paying for services), and that the requester is one of the registry contact people/ contact role-account. + resource efficient. We only deal with people who are experienced in the reverse delegation procedure and aware of the RIPE NCC and RIPE DB procedures in general -> minimal time explaining procedure and general registry system concepts. Currently we spend much time dealing with inexperienced end-users who will set up only one or a few zones and therefore do not spend the time to become knowledgable concerning the procedures. + fair to paying members. We do not spend time guiding people who do not contribute to the costs. ---> We will only accept requests in the form of a RIPE DB domain object (as opposed to also accepting inetnum objects). + uniform update procedure for all types and sizes of zone, procedure becomes much clearer, confusion and doubt are banished. + removes possibility of 3-way inconsistency between domain objects in the RIPE DB, inetnum objects in the RIPE DB and the corresponding zone file delegations. + clear to users of DB in what type of object they need to look for contact info on the zone. + removes problem where errors in a single reverse zone of a corresponding large inetnum mean the whole inetnum has to be resubmitted, - for requests involving large numbers of zones lots of domain objects will be needed. We'll lessen this by making possible a shorthand domain object like this: domain: x-y.w.z.in-addr.arpa This will result in all reverse zones x-y being delegated (upon success), and x-y domain objects being entered in the database. This option will only be possible for corresponding address space which is occupied by a single inetnum object, to reduce the possibilty of misuse/mistakes. Thanks in advance for any input, Lee Wilmot RIPE NCC

1 0

RIPE 34 LIR WG Draft Agenda [SPT1999091000000043]
by support＠waldonet.net.mt 10 Sep '99

10 Sep '99

Dear lir-wg(a)ripe.net, This is an automated response from Support Pools . We received your message on 10/09/99 at 5:11:32 PM. We would like to offer our sincere thanks to you for writing to us. Your tracking number for this message is : SPT1999091000000043. Our staff are available to respond to messages during regular business hours, excluding holidays. Messages are normally answered within one business day. You should be receiving a personal response by e-mail from one of our staff shortly. In the event you need to contact us regarding your original message, please refer to the tracking number at the top of this message. This will help our staff locate and review your correspondence with us. Thanks once again for writing. You should hear from one of our staff shortly. Waldonet Ltd Telephone (Sales & Admin) 419100 Telephone (Customer Support) 419200 Fax: 419300

1 0

RIPE 34 LIR WG Draft Agenda
by hph＠sys.sol.no 10 Sep '99

10 Sep '99

Dear Working Group Member ! I have put together a first draft of the agenda for the upcoming working group meeting. Please read it carefully and make suggestions for additions and changes. Remember: this is YOUR forum, please send me YOUR suggestions on what you want us to spend time on at the meeting in Amsterdam, Looking forward to meet you there, Hans Petter Holen LIR WG Chair ---------------------------------------------------- RIPE 34 - Local IR Working Group first draft Agenda 1. Admin scribe participant list charter mailinglists 2. Agenda 3. Introduction of the new Registration Services manager, Nurani Nimpuno. meet the RIPE NCC hostmasters 4. RIPE 33 minutes actions 5. Reports from the Registries RIPE APNIC 6. The RIPE community POLICY making process by Mirjam Discussion: is this well understood and 7. ICANN - ASO Current status, Further work Definition of the selection procedure for the address council selection 8. AOB

1 0

MoU based ASO proposal accepted by ICANN
by RIPE NCC Staff 08 Sep '99

08 Sep '99

[Apologies for duplicate mails] This is an update to our earlier posting regarding a proposal to form an Address Supporting Organisation (ASO) within the framework of the International Corporation for the Assignment of Names and Numbers (ICANN). RIPE NCC, together with the other Regional Internet Registries (RIR), ARIN and APNIC submitted this proposal for ICANN to consider at their August 26th Board meeting in Santiago, Chile. The RIPE NCC is pleased to report that ICANN has accepted this proposal. The resolutions approved at the recent ICANN Board meeting can be found at: http://www.icann.org/santiago/santiago-resolutions.htm The RIR Boards have worked to produce a draft Memorandum of Understanding that will form the ASO. This document can be found at: http://www.ripe.net/info/ncc/mou-draft.html In addition we need to progress with the selection of nominations for the Address Council. A formal call for nominations has been published outlining the process of the initial formation of the Address Council. The call for nominations can be found at: http://www.ripe.net/info/ncc/asonomin.html We would like thank you for your continued support in this process. Paul Rendek Communications Officer RIPE NCC

1 0

ICANN: Call for nominees to the Addres Council
by RIPE NCC Staff 08 Sep '99

08 Sep '99

Dear Colleagues, We are pleased to announce a call for nominations to the ICANN ASO committee. Please read this carefully as it is an important step in the process of furthering development in this area. In our effort to reach as many interested parties as possible we may unavoidably send you two copies. Please accept our apologies for this. ========= Call for Nominations for Members of the Address Council of ICANN - RIPE NCC Service Region Amsterdam, 8 September 1999 This is a call for nominations of individuals to serve as members of the Address Council, a body that is to be established under the authority of the Address Supporting Organisation (ASO) of ICANN. This document describes the process that will be followed in the selection of Address Council members. If you are interested in nominating an individual, or if you are interested in being nominated as a member of the Address Council, please read through the Memorandum of Understanding (MoU) and this document carefully. 1. The Address Supporting Organisation ----------------------------------------------------- The ASO will be created though a MoU that will be executed between the current Regional Internet Registries (RIRs) and ICANN. The latest version of this MoU is available under the ICANN and ASO current issues section on the RIPE NCC Web site at: http://www.ripe.net/info/ncc/icann.html Section 2(a) of the MoU provides a framework for the regional selection procedure of Address Council members. Due to additional time constraints set by the current ICANN board the schedule proposed in section 2(a) cannot be realised. Therefore in accordance with section 2(a)(v) a modified procedure will be followed to select the initial Address Council members with emphasis on openness and transparency. The RIPE NCC Association has chosen to make use of the existing open processes in their region to select Address Council members. The selection of the Address Council members will take place at the first following RIPE Meeting scheduled to take place from 21-24 September 1999 in Amsterdam, The Netherlands. In accordance with section 2(a)(v) the definition of the selection procedure will be part of the Local Internet Registry Working Group (Local IR WG) meeting scheduled for Wednesday, 22 September 1999 at 14:00 at the upcoming RIPE meeting. This working group has traditionally served as the RIPE NCC's IP address related policy making forum and is open to all interested parties. The actual selection will take place at the RIPE 34 Meeting - Plenary session to be held on Thursday, 23 September 1999 starting at 14:00. Further information about the upcoming RIPE Meeting can be found at: http://www.ripe.net/meetings/ripe/index.htmlripe-34/ 2. Address Council Nominations Process ------------------------------------------------------ Three individuals from the RIPE NCC Region will be selected to serve as initial members of the Address Council. The selection will be made from the set of individuals who have been nominated within this process. Any individual may be nominated within this process, with the exception of any staff member of any Regional Internet Registry. Self-nominations are permitted. Nominations are to be sent by email to: nominations(a)ripe.net The information included with the nomination is to be in English, and should include: Name of Nominee Organisation Email Address Postal Address Phone Number Motivation for Nomination All nominations are to be emailed to the above address on or before Sunday, 19 September 1999. All nominees will be contacted via email to confirm their willingness to serve as an Address Council member. If the nominee cannot be contacted via email then the nomination will not be confirmed. All confirmed nominations will be listed on the RIPE NCC Web site as soon as they are confirmed. Important Dates: 19 September 1999: deadline for Address Council nominations 21-24 September 1999: RIPE Meeting 34 - Amsterdam, The Netherlands Keith Mitchell, Chairman, RIPE NCC Executive Board Rob Blokzijl, Chairman, RIPE

1 0

Tracking stealth portscan/pepsi attacks
by Petra Zeidler 07 Sep '99

07 Sep '99

Dear colleagues, there seems to have been quite a wash of stealth portscans and/or pepsi attacks lately (stealth portscan: you portscan with 99% of the sender addresses faked, but your own are among them; pepsi: "only" a DoS attack, you don't bother hiding your own address in the random sender flood, both of course UDP). cybercity.dk must have been seeing some of these attacks pass, first glance judging from http://stat.cybercity.dk/ripe/ and the fallout in de.xlink (where I positively know the addresses not to be routed) and de.zz (where most of the address space is handled by RIPE nowadays). Also my private machine at home has been attacked over several days, much good it did them, but that makes it a personal axe to grind :-> Besides, lots of people who admin firewalls don't necessarily expect such stealth attacks to happen and complain to all the owners of the faked addresses about the port scans, thus generation additional workload on the abuse people. I'd like to have a chance to catch the perpetrators. This would need to be a multi-provider cooperation in the majority of cases. Do we have an appropriate forum to discuss this at the next RIPE meeting? kind regards, Petra Zeidler -- i.A. Petra Zeidler, Neukundenanschluss Xlink Internet Service GmbH [X] zeidler(a)xlink.net [X] Tel: 0721/9652-220 [X] Fax: 0721/9652-209 [X] Geschaeftsfuehrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. [X] Auftraege erledigen wir zu unseren Allgemeinen Geschaeftsbedingungen.

14 24

Top 100 Maintainers List
by RIPE Database Administration 06 Sep '99

06 Sep '99

3 2